Hallo, ich möchte in meinem 5er BMW BJ 2005 ein Infotainment-System einbauen, das über einen Odroid M1 bzw. einen RPI läuft. Dazu möchte ich openDash nutzen und ein separates Display verbauen. In dem BMW ist ein CCC verbaut mit einem 6,5" Display mit einer Auflösung von 400x240. OpenDash unterstützt auch die Möglichkeit einen Kamera-Input anzuzeigen. Und über diesen Kamera-Input würde ich gerne das CCC Video-Signal anzeigen lassen, damit ich die Fahrzeugfunktionen noch nutzen kann. Nach meiner bisherigen Recherche habe ich herausgefunden, dass BMW ein 6-Bit (18-Bit für alle 3 Farben), 1 Kanal LVDS Signal + 2Kabel für das Clock Signal nutzt, um das Display zu versorgen. Das ganze läuft dann über FPD-Link I. Wie kann ich am besten das Video Signal auf dem Odroid/RPI anzeigen lassen? Ich habe bisher auf Aliexpress einen LVDS->HDMI Adapter gefunden. Die günstigen HDMI Capture Cards über USB, die man auf ebay findet, akzeptieren scheinbar aber keine so kleinen Auflösungen. Das habe ich mal mit meinem RPI simuliert, indem ich die Auflösung auf 400x240 gestellt habe. Damit habe ich über die HDMI Capture Card kein Signal angezeigt bekommen. Es gibt scheinbar auch USB Videograbber, die composite Videosignale aufnehmen können, aber da weiß ich auch nicht, ob die Auflösung unterstützt wird. Und das Videosignal müsste vorher auch noch konvertiert werden. RPI und der Odroid verfügen beide über einen MIPI-CSI2 Port, USB und GPIO. Fällt euch eine Lösung ein, wie man das Signal möglichst einfach anzeigen lassen kann? Mir gehen da leider die Ideen aus. Als absolute Notlösung ist mir nur eingefallen eine USB Webcam auf das "alte" Display zu richten. Aber das möchte ich nach Möglichkeit vermeiden, da die Lösung denkbar ungeschickt ist. Ich habe einen Chip von Ti gefunden, der wohl 18-Bit FPD-Link -> TTL konvertieren kann, aber wie kommt man von TTL wieder auf USB oder ähnliches? https://www.ti.com/product/de-de/DS90CF364 Pinbelegung vom BMW LVDS-Stecker 1 -> LVDS Channel 2+ 2 -> LVDS Channel 2- 3 -> -- 4 -> LVDS Channel 1+ 5 -> LVDS Channel 1- 6 -> LVDS clock + 7 -> LCDS clock - 8 -> -- 9 -> LVDS Channel 0+ 10 -> LVDS Channel 0-
:
Bearbeitet durch User
Moin, Mir ist recht unklar, was du da wirklich vorhast. Eine simple Zeichnung mit ein paar beschrifteten Bloecken (was wo momentan ueber welches Interface raus und reingeht und was in Zukunft gehen soll) koennte da weiterhelfen. Allgemein ist's halt so, dass alles Video, was ueber analog FBAS hinausgeht, immer ganz schnell unangenehm aufwendig wird. So mit impedanzkontrollierten Signalen, "Kopier"schutz und Chips, an die und deren Datenblaettern man schwer kommt... Gruss WK
Mein Vorhaben ist eigentlich relativ einfach erklärt. Ich möchte das LVDS Signal vom BMW CCC abgreifen und auf dem RPI/Odroid anzeigen lassen.
Max schrieb: > Das ganze läuft dann über FPD-Link I. > > Wie kann ich am besten das Video Signal auf dem Odroid/RPI anzeigen > lassen? Es gibt Frame Grabber dafür. Allerdings sind das keine Massenprodukte, sondern werden z.B. zum Testen von solchen Automotive-Lösungen eingesetzt und liegen preislich vermutlich über dem Zeitwert Deines Fahrzeugs. Was man häufiger findet, sind Lösungen, um auf dem werksseitig verbauten Display etwas Externes (und auf Wunsch das Originalbild) anzeigen zu lassen. Damit das von der Auflösung her brauchbar wird, müsstest Du aber wahrscheinlich erstmal vom CCC auf das CIC umrüsten.
Moin, Ich bin da sehr pessimistisch was die Erfolgsaussichten angeht. Tu' dich vielleicht mit diesem Kollegen: Beitrag "Wie kann man Mikrocontroller kaufen und programmieren" zusammen, das erscheint mir aehnlich ambitioniert. Gruss WK
Max schrieb: > Ich möchte das > LVDS Signal vom BMW CCC abgreifen und auf dem RPI/Odroid anzeigen > lassen. Das Problem ist die sehr niedrige Auflösung des Displays (und damit des Signals), die deutlich unterhalb von allem liegen, was als Standardauflösung im PC-/Fernsehbereich verwendet wird. Um mit den von Dir erwähnten Dingen (Framegrabber o.ä.) Erfolg zu haben, brauchst Du einen Skalierer, der aus dem niedrigaufgelösten Signal eines mit einer etablierten Standardauflösung und der standardüblichen Abtastrate erzeugt. Da wird eine Verdoppelung in X- und Y-Richtung genügen, damit kommst Du auf 800x480, was als WVGA (bei 60p) so ziemlich das niedrigste des allgemein akzeptierten sein dürfte. Jemand, der sich wirklich gut mit FPGAs auskennt, kann damit sicherlich so einen Skalierer und gegebenenfalls Abtastratenkonverter erzeugen. Ebenfalls mit so einem FPGA könnte man auch den analogen Weg gehen und ein 16:9-NTSC-Signal mit 480i oder ein 16:9-PAL-Signal mit 576i erzeugen. Das wiederum ließe sich mit einem USB-Composite-Grabber erfassen.
Wer schon ein FPGA einsetzen kann, macht damit gleich den Framegrabber für das Display-Signal! Wenn man das Signal schon im FPGA einliest, konvertiert man es doch nicht unnötig in ein anderes Videosignal, um dieses mit einem weiteren Framegrabber wieder einzulesen. Da schafft man sich gleich ein Interface zum Rechnersystem, was sonst den Framegrabber angeschlossen bekäme.
Vielleicht kann man einen SN75LVDS86 verwenden, der die seriellen LVDS Signale in parallele Daten umwandelt, die man dann über GPIOs o.a. einlesen kann, um sie dann eventuell in der Auflösung angepasst in einem Framebuffer zur Darstellung abspeichern zu können. Fraglich ist, ob der SN75LVDS86 die niedrige Auflösung verarbeiten kann.
Ich glaube das umwandeln vom seriellen LVDS Signal nach parallel RGB wird von dem verbauten Board hinter dem Display erledigt. Evtl. kann ja auch das Signal abgegriffen werden. Habe mir ja erhofft, dass es vielleicht in irgendwelchem Ecken auf Aliexpress ein Adapterboard gibt, dass man nutzen könnte. Das Display hier ist bei mir verbaut: https://www.panelook.com/LQ065T9DR51U_Sharp_6.5_LCM_parameter_9588.html Signal: Parallel RGB (1 ch, 6-bit), 31 pins
Old schrieb: > Fraglich ist, ob der SN75LVDS86 die niedrige Auflösung verarbeiten kann. Die Auflösung ist dem egal, kritisch ist der Takt, der bei dieser Anwendung recht sicher deutlich unter dem Minimum von 31 MHz liegen dürfte. Obendrein ist das ein 7-Bit-Baustein, ob das zum Bildsignal passt?
Harald K. schrieb: > Obendrein ist das ein 7-Bit-Baustein, ob das zum Bildsignal passt? Ja, das passt, weil jeweils 1 der 7 Bits ein Sync/Blank Signal ist und die restlichen 6 dann die jeweilige Farbe. Aber der minimale Takt ist ein Problem, der vom TO vorgeschlagene DS90CF364 geht bissl weiter runter, vielleicht koennte der das grad' ab - muesste man halt mal den Takt messen - aber selbst wenn: das hilft ja nicht so wirklich weiter. Denn dann haste 'nen breiten Bus mit Pixel- und Syncsignalen - und das ist genauso aufwendig auf "USB" bzw. MIPI-CSI zu bringen wie das nackerte LVDS. Klar' kann's mit einem FPGA gehen (Da waere auch der "niedrige" LVDS Takt kein Problem), aber ein CSI Core wird nicht ganz billig sein, die vollstaendige CSI Spec ist's auch nicht und wenn der TO in der Richtung FPGAs "programmieren" koennte, haette er hier nicht gefragt. Mein Pessimismus ist nicht ganz grundlos. Gruss WK
Dergute W. schrieb: > Ja, das passt, weil jeweils 1 der 7 Bits ein Sync/Blank Signal ist und > die restlichen 6 dann die jeweilige Farbe. Du kennst das verbaute Display? Dergute W. schrieb: > Mein Pessimismus ist nicht ganz grundlos. Da bist Du ganz und gar nicht allein.
Moin, Harald K. schrieb: > Du kennst das verbaute Display? Nein, aber 3 und 4 laneiges LVDS. Gruss WK
:
Bearbeitet durch User
Ja schade. Da ich keine FPGA Kenntnisse habe, wird die Umsetzung von dem Vorhaben wohl erstmal nichts werden. Aber rein aus Interesse. Wäre es nicht am einfachsten wenn man einen FPGA nutzt und das Videosignal dann ohne upscaling quasi wie eine USB-webcam (UVC) ausgibt? Upscalen könnte man ja dann über Gstreamer auf dem Odroid.
:
Bearbeitet durch User
Ja. Aber USB ist wieder kompliziert, da muss man das Video encodieren, einpacken, USB sprechen, ... Das LVDS BMW Video rein und auf der anderen Seite HDMI raus, das wäre einfach.
Max schrieb: > Wäre es nicht am einfachsten wenn man einen > FPGA nutzt und das Videosignal dann ohne upscaling quasi wie eine > USB-webcam (UVC) ausgibt? Ob sowas "einfach" ist, liegt im Auge des Betrachters. Es müsste der UVC-Standard genau betrachtet werden, ob eine der dort definierten "Payloads" (Videoformate) zu dem passt, was das Display anzeigt, d.h. die Auflösung müsste (grob) passen und aber auch die Framerate. Die ersten USB-Videokameras hatten so niedrige Auflösungen wie dieses Display, aber auch noch sehr, sehr niedrige Frameraten (15 fps o.ä.). Aber ja, ein Ansatz wäre es. Was Du allerdings auch noch klären müsstest: Ist die Ausgangsleistung des verwendeten LDVS-Treibers im kryptisch mit "CCC" bezeichneten Gerät ausreichend, um mehr als einen LVDS-Empfänger zu versorgen? Denn Du müsstest für Deinen Ansatz, egal, wie er im Detail aussieht, auf jeden Fall zwei LVDS-Empfänger parallelschalten, den des Displays und den Deiner Lösung.
Wenn man schon einen FPGA verwendet, dann hat der für diese Aufgabe vermutlich zu viele IOs, man hat also welche übrig und kann damit das LVDS wieder ausgeben. Quasi ein LVDS Repeater.
Moin, Max schrieb: > Aber rein aus Interesse. Wäre es nicht am einfachsten wenn man einen > FPGA nutzt und das Videosignal dann ohne upscaling quasi wie eine > USB-webcam (UVC) ausgibt? Upscalen könnte man ja dann über Gstreamer auf > dem Odroid. Klar, koennte man so machen. Aber jenachdem, wie gross/voll dein FPGA ist und wieviel Rechenbumms du auf dem Odroid noch fuer was anderes brauchst, koennte es auch Vorteile haben, ein Videosignal im FPGA zu skalieren. Im Gegensatz zu dem USB- bzw. MIPI-CSI-Gehampel ist skalieren im FPGA eher uebersichtlich vom "Programmier"aufwand her... Gruss WK
Für FPD-Link III hatte ich bei einer Recherche mal Boards gefunden, die das auf MIPI CSI2 konvertieren können. Vielleicht gibt es sowas auch für FPD-Link I, oder hast du das schon recherchiert? Ansonsten kann ich mich erinnern dass Lattice Video-Konverter auf Basis ihrer FPGAs anbietet bei denen man die Logik im FPGA nicht selbst zusammenstellen muss. Ist aber etliche Jahre her dass ich das gesehen hatte aber vielleicht gibt's da ja was passendes.
Hmmm schrieb: > Es gibt Frame Grabber dafür. Allerdings sind das keine Massenprodukte, > sondern werden z.B. zum Testen von solchen Automotive-Lösungen > eingesetzt und liegen preislich vermutlich über dem Zeitwert Deines > Fahrzeugs. Da das System um das es hier geht vor um die 20 Jahren entwickelt worden ist, dürften solche Tools mittlerweile schon zum größten Teil ausgemustert worden sein. Vermutlich aber eher verschrottet als bei eBay versteigert, wären jetzt also vermutlich nur mit viel Glück zu bekommen...
Thread beobachten
Seitenaufteilung abschaltenBitte 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.