Hi zusammen.
Ich versuche ein Display mit 480x240 per HDMI anzusteuern. Dazu verwende
ich ein Board, das den HDMI mit einem AD7611 anbindet.
Ich erzeuge mit dem nVidia-Treiber eine eigene Auflösung:
1
aktiv...480..240
2
fporch...35....3
3
sync.....20....2
4
gesamt..550..247
5
pol.......n....n
Das ergibt laut Treiber ein hsync von 14,82kHz, ein vsync von 60Hz und
einen Pixeltakt von 8,151MHz.
Wenn ich am AD7611 messe, sehe ich mit dem Oszi aber 11,76MHz. Wenn ich
mit einem anderen Display teste, und dort auf 1280x480 mit allen Werten
einstelle, gibt mir der Treiber 40MHz Pixeltakt aus. Diese messe ich
auch exakt mit dem Oszi. da sehe ich auch ein Bild auf dem Display, im
ersten Fall nicht.
Warum ist der Takt höher, als mir Treiber (und Datenblatt) sagen? Wie
kann ich nVidia dazu bringen, den korrekten Takt zu verwenden?
Sowas hatte ich vermutet, allerdings habe ich kein brauchbares
Datenblatt der Grafikkarte gefunden in der sowas steht. Im konkreten
Rechner ist eine Quadro K620, aber da finde ich höchstens maximalen
Pixeltakt.
Das wird auch nicht im Datenblatt der Graphikkarte drinstehen, sondern
in der HDMI-Spezifikation. Unter Standard-VGA (640x480) ist halt nix
drin.
Was Du machen kannst: Halbiere den Pixeltakt auf Empfängerseite und wirf
jedes zweite empfangene Pixel weg.
Mach das gleiche mit dem Zeilentakt, und werte nur gerade oder nur
ungerade Zeilen aus.
Damit kannst Du per EDID-EEPROM am HDMI-Stecker eine Auflösung von
960x480 vorgaukeln, was der Treiber der Graphikkarte ohne weitere
Verrenkungen Deinerseits direkt "bespielen" können müsste.
Was für ein ungewöhnliches Display mit einem Seitenverhältnis von 2:1
ist das eigentlich?
Danke für eure Antworten.
Das Display ist ein ACX416AKN bzw ein fast baugleiches ACX453AKC, zu
letzterem habe ich ein Datenblatt auftreiben können.
Der Aufbau ist:
PC - HDMI - ADV7611 - DS90C385AMT - INAP375T - mb88f332 Indigo -
ACX416AKN
HDMI wird umgesetzt zu 18bit RGB + VS/HS/DE, danach wirds zu LVDS. Das
liegt am INAP375 an, wird zu APIX, kommt zum Indigo und der gibts zum
Panel.
Ich habe keine Möglichkeit, den Pixeltakt nach der Ausgabe noch zu
beeinflussen, bzw Pixel wegzuwerfen.
Kann man das irgendwie so einstellen auf Treiberseite, dass das Display
halt zB nur den oberen linken Bildschirmausschnitt anzeigt, und alles
andere verloren geht und abgeschnitten wird?
Danke für den Tipp mit dem Datenblatt, das hatte ich nicht gesehen.
Allerdings wundert es mich, dass es eine untere Grenze gibt die doch so
hoch liegt.
Stefan M. schrieb:> Danke für den Tipp mit dem Datenblatt, das hatte ich nicht gesehen.> Allerdings wundert es mich, dass es eine untere Grenze gibt die doch so> hoch liegt.
Das wird an der internen PLL liegen, da ist ganz normal dass die eine
untere Grenze haben. Ich kenne jetzt nicht alle erlaubten HDMI Modes,
aber ich schaetze mal, das ist immer noch weit unterhalb des kleinsten
spezifizierten Pixeltakts.
Von daher sollte man eher froh sein, dass man soweit runter kommt. ;-)
Ich hab mir das Datenblatt nochmal angesehen. Anscheinend kann das
Display auch 13MHz Pixeltakt, wenn man sich nicht an den typischen
Werten orientiert, sondern eher Richtung Maximum geht. Das muss ich
nachher ausprobieren.
Btw, auf deiner "Über mich" Seite steht Leiderschaft. Muss das so sein
:)
Stefan M. schrieb:> Ich habe keine Möglichkeit, den Pixeltakt nach der Ausgabe noch zu> beeinflussen, bzw Pixel wegzuwerfen.
Den Pixeltakt kannst Du recht einfach beeinflussen, und zwar zwischen
HDMI-Receiver und LVDS-Transmitter. Da könntest Du ein T-Flipflop
dazwischenklemmen, das als Taktteiler fungiert.
Die geringe Zeilenzahl ist allerdings ein Problem. Das wird vermutlich
nicht ganz so einfach.
Was ist das Ziel der Übung? Warum willst Du ein 1.8"-Display mit so
geringer Auflösung mit einem HDMI-Signal ansteuern?
Das Ziel der Übung: Dieses 1,8" Display steckt im HUD von meinem BMW
F30. Ich habe mir Nachtsicht aus dem 5er nachgerüstet, und will mir das
Bild im HUD anzeigen.
Deswegen will ich eine Umschaltlösung bauen, die den APIX-Datenstrom vom
Kombi trennt und stattdessen das Bild von der Nachtsicht-Cam darstellt.
Dazu ist aber der erste Schritt, dass ich überhaupt ein Bild auf dem
Display ausgeben kann.
Stefan M. schrieb:> und stattdessen das Bild von der Nachtsicht-Cam darstellt.
Und in welchem Datenformat/mit welcher Auflösung liefert die ihr Bild?
Etwa HDMI?
Vermutlich ist der (Um-) Weg über ein analoges Videosignal hier
einfacher. HDMI lässt mit kostengünstigen Wandlern in
PAL-Composite-Video-Signale konvertieren, und die HDMI-Quelle muss dabei
nichts von der niedrigen PAL-Auflösung wissen, um das "downscaling"
kümmert sich die spottbillige Wandlerelektronik (die scheint 720p und
1080p als Quellformate zu unterstützen).
https://www.amazon.de/GANA-Konverter-Composite-Adapter-Ladekabel-Blau/dp/B06XJTV33G/
Es dürfte deutlich einfacher sein, aus diesem Signal wiederum irgendwas
zu konstruieren, was Du in Dein HUD einspeisen kannst.
Die Nachtsichtcam liefert PAL in den Analog-Video-Eingang der Headunit.
Das hätte ich mit nem Y-Adapter gesplittet, in meinem CarPC auf HDMI
gewandelt und von dort in die "HDMI - ADV7611 - DS90C385AMT - INAP375T -
mb88f332 Indigo" Adapterplatine gefüttert.
Die HUD-Ansteuerplatine kann ja leider nur HDMI, keine analogen Quellen.
Sonst wärs ja einfach :D
Ich möchte eigentlich auch noch eine eigene Platine entwickeln, sehe
aber Probleme mit dem Pixeltakt. Der PTN3460 den ich im Sinn hatte, kann
nur bis 25MHz runter. Das ist ja viel zu viel...
Gibts die nicht auch noch langsamer, am besten für DisplayPort?
Stefan M. schrieb:> Der PTN3460 den ich im Sinn hatte, kann nur bis 25MHz runter. Das ist ja> viel zu viel...>> Gibts die nicht auch noch langsamer, am besten für DisplayPort?
Mit LVDS, HDMI, DP und Co wird das schwer. Wie schon gesagt unter VGA
Auflösung ist eher ungewöhnlich. Tobias hat dir auch eine technische
Erklärung geliefert warum das so ist. Rufus mit der Übertragung von
größeren dann teils nichtgenutztem Displayinhalt eine mögliche Lösung.
Stefan M. schrieb:> Die Nachtsichtcam liefert PAL in den Analog-Video-Eingang der Headunit.
Das passt doch nicht zu dem, was Du bislang geschrieben hast.
Du hast ein HUD, das von irgendwas auf mystische Weise angesteuert wird
(aber nicht analog) und möchstest da eine analoge Signalquelle
dranhängen.
Was hat jetzt der "CarPC" damit zu tun?
Oder gehören HUD und Kamera zusammen und Du möchtest zusätzlich noch das
Signal Deines "CarPC" auf dem Display darstellen können?
Hab ich euch sauber verwirrt :)
Eigentlich passt es ganz gut zusammen. Aber ich erklärs nochmal
zusammenfassend.
Serienzustand:
Auto mit Kombi und HUD, Kombi schickt Bilddaten per APIX ans HUD.
Nachtsichtcam schickt Bilddaten per analog PAL an die Headunit.
Ziel:
Bilddaten von Nachtsichtcam sollen im HUD dargestellt werden.
Einziger Weg um Bilddaten ins HUD zu bekommen: APIX (mein mystisches
Adapterboard), das INAP375T TRANSMITTER BOARD von Inova das ich vor
Jahren mal bei ebay schießen konnte.
https://inova-semiconductors.de/inap375t-transmitter-board.html
Dort ist der AD7611 drauf, auf den sich meine Eingangsfrage bezieht. In
das Board kann ich nur mit HDMI rein.
Mein Plan:
PAL-Signal im CarPC digitalisieren, CarPC per HDMI ans Inova-Board, und
dieses Bild dann auf dem HUD darstellen.
Im zweiten Schritt dann eine wie auch immer geartete Umschaltlösung.
Stefan M. schrieb:> PAL-Signal im CarPC digitalisieren, CarPC per HDMI ans Inova-Board, und> dieses Bild dann auf dem HUD darstellen.
Ist so nicht umsetzbar, da Dein CarPC nicht das verquere Timing
produzieren kann, das das Display benötigt. Dein "HDMI-zu-APEX"-Umsetzer
scheint nicht die richtige Wahl zu sein, wenn er der HDMI-Quelle ein
HDMI-Signal mit nicht standardkonformem Timing vorgibt.
Du solltest eher nach einem Weg suchen, ein APIX-Signal direkt aus einem
Composite-Video-Signal zu erzeugen.
Das "Kombi" (ich liebe diese sinnentstellenden und damit -losen
Abkürzungen) sieht nicht vor, irgendwo irgendwelche Videosignale
einzuspeisen?
Das Kombi, oder Kombi-Instrument ist das, was man früher Tacho nannte.
Ich dachte das ist ein üblicher Begriff. Das hat keine Videoeingänge,
dort sitzt der Grafikchip (iirc ein Jade-D von Fujitsu), der das Bild
rechnet und dann ans HUD überträgt.
APIX direkt aus composite geht afaik nicht, denn die INAP375T haben nur
digitale Eingänge, entweder für LVDS oder 18/24bit RGB parallel. Evtl
gibt es ja Umwandler von composite auf RGB oder LVDS, so dass ich das
Problem des HDMI-Pixeltakts umgehen kann.
Stefan M. schrieb:> Evtl gibt es ja Umwandler von composite auf RGB oder LVDS,
Die werden nicht helfen, weil das Display mit seiner merkwürdigen
Auflösung natürlich nicht mit dem normalen PAL-Timing "bespielt" werden
kann.
Du bräuchtest einen programmierbaren Abtastratenkonverter. Der aber ist
erheblicher Aufriss.
"Eigentlich" bräuchte ich nur einen HDMI/DV/DP auf LVDS Umsetzer, der
mit 10MHz Pixeltakt klar kommt? Irgendwie riecht das alles nach FPGA,
der mir dann ais meinen Signalen genau das richtige schnitzt.
Beispielsweise könnte ich mit VGA rein, alles was zu viel ist
wegschneiden und das was übrig bleibt in den INAP375T füttern. Dann ist
die HDMI-Spec erfüllt, und der INAP375T hat kein problem mit so geringen
Takten.
Stefan M. schrieb:> HDMI/DV/DP auf LVDS Umsetzer, der mit 10MHz Pixeltakt klar kommt?
So einfach ist das nicht. Du hast eine wie auch immer geartete Hardware,
die ein HDMI-Signal erzeugt, dies aber nur innerhalb gewisser Parameter
kann - ob das nun die Graphikkarte in Deinem "CarPC" oder ein DVD-Player
oder ein Composite-Video-zu-HDMI-Umsetzer ist. Diese "gewissen
Parameter" sind eine Liste von Standard-Videotimings, 1080p, 720p oder
die üblichen PC-Auflösungen. Und die geben damit auch den Pixeltakt vor,
der ganz erheblich über Deinen 10 MHz liegt.
Dein gewünschter Umsetzer müsste eine Abtastratenkonvertierung vornehmen
und ein (z.B.) 720p-Signal in Dein Ultra-Low-Res-Signal umrechnen,
d.h. ein zu Deinem Display passendes Timing inklusive Pixeltakt
erzeugen.
> Beispielsweise könnte ich mit VGA rein, alles was zu viel ist> wegschneiden
Äh, ja, so einfach kann man das natürlich beschreiben, was ein
Abtastratenkonverter macht, aber das ist alles andere als trivial.
Das Ding müsste a) eine standardkonforme HDMI-Senke mit wenigstens einem
Timing sein, das die HDMI-Quelle liefern kann, also z.B. 720p.
Dann müsste es b) einen Speicher für komplette Bilder enthalten und
diesen Speicher mit dem HDMI-Signal der Quelle befüllen. Zeitgleich
müsste es völlig asynchron und deutlich langsamer diesen Speicher
selektiv wieder auslesen (um Deinen "Beschnitt" zu erzeugen) und daraus
ein Signal mit Deinem gewünschten Timing für Dein Display zu erzeugen.
Kann man mit einem FPGA sicherlich irgendwie hinbekommen, ist aber eben
ganz schöner Aufriss.
Thread beobachten
Seitenaufteilung abschalten