Angepinnt MCA-Plus als Display für Videoquellen nutzen

    Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

      MCA-Plus als Display für Videoquellen nutzen

      Hab mal wieder gebastelt, so auf die Schnelle für zwischendurch :)
      Und zwar hab ich mir aus ebay einen solchen VGA zu Composite-Video (FBAS) gekauft. Bewusst nicht das einfachste, billigste (gibt da auch auch welche die nur aussehen wie Stecker, aber denen vertraue ich nicht...) aber durchaus erschwinglich. Den hab ich heut Abend mal auf den Video-Eingang von meinem MCA gelegt und damit mein Laptop-Bild aufs Display gespiegelt, coole Sache :D
      Hier ein paar Bilder und ein Video davon:



      Da hat es sich doch schon gelohnt, das ich damals beim Umbau von MCA auf MCA-Plus den Pigtail ins Handschuhfach gelegt hab und nicht andersrum über die Fahrerseite. So konnte ich da ratzfatz ran, ohne das Navi auszubauen.
      Das war nur eine Spielerei, denn ich benötige ein paar valide Videoquellen, da ich derzeit einen Videoumschalter konstruiere. Das soll schon was gescheites sein, nix mit Relais oder so. Am Ende soll der Aufbau in der Lage sein beim anlegen eines Videosignals an einer der Eingange selbstständig auf diesen zu wechseln und das Bild im MCA anzeigen. Die Eingänge sind priorisiert, so kann man z.B. an Video-P1 die Rückfahrkamera anschließen. Immer wenn die ein Bild liefert, wird darauf gewechselt, so wie im Original. An Video-P2 dann z.B. ne Frontkamera und an Video-P3 einen Mediaplayer oder ein Andriod für geile Navigation, oder was weiß ich ;) Auch Audio will ich damit schalten.

      Bis dahin ist noch einiges zu tun, denn das ist alles andere als trivial, will man es sauber implementieren, sodass alle Funktionen erhalten bleiben, z.B. jederzeit ein Wechsel auf Radio oder Nav oder Klima möglich ist und man über AUX wieder zum Video zurückkehrt. Mal schaun was der STM32 so alles drauf hat und ob er auch in der Lage ist per Bluetooth oder WLAN zu streamen.

      Nichtsdestotrotz ist die Auflösung des MCA mehr als bescheiden, also darf man keine Wunder erwarten. Auch wenn man den XP Desktop erkennen kann, so kann man nix lesen, obwohl der auf 800x600 eingestellt ist, was der nativen Auflösung des Displays entspricht. Aber das ist auch klar, denn das Signal ist ja nicht digital und wer schonmal früher ein PC-Bild auf den Fernseher (egal ob Röhre oder Flat) gelegt hat, kennt das.

      Eine digitale Videoschnittstelle gibt es nicht, zumindest nicht nach außen geführt. Der A/D-Wandler steckt im zusätzlichen Videodecoder-Chip auf der Displayplatine. Ich schaus mir mal an, aber da wird nix gehen fürchte ich. Also muss man mit potentiell unscharfen Bildern leben, auch wenn das Display theoretisch mehr könnte.

      Achja, zu allem Übel ist das MCA+ wohl auf eine NTSC-Quelle angewiesen. Auf PAL umgeschaltet (was das eigentlich bessere Videoformat wäre) kommt Matsche.

      Gute Nacht!
      Ach, vielleicht doch noch eine kleine Gute-Nacht-Story noch zu dem Videochip auf dem MCA-Displayboard :)

      Das fiese ist, das der von hause aus einen 6-fach Multiplexer drin hat. D.H. wenn die Software das unterstützen würde, könnte das MCA+ von Werk auf 6 Analoge FBAS-Quellen verwalten, ohne zusatzbauteile und Kosten (naja, die Buchsen halt). Gemein, oder? Und wir bauen jetzt alles drumrum...

      Auch könnte der Chip neben FBAS direkt digitale Signale aufnehmen, sogar RGB, da jedoch nur mit einem Eingang.

      Go4IT schrieb:

      Die Eingänge sind priorisiert, so kann man z.B. an Video-P1 die Rückfahrkamera anschließen. Immer wenn die ein Bild liefert, wird darauf gewechselt, so wie im Original. An Video-P2 dann z.B. ne Frontkamera und an Video-P3 einen Mediaplayer oder ein Andriod für geile Navigation, oder was weiß ich Auch Audio will ich damit schalten.


      Wenn man das ganze dann noch per "Bild im Bild" sprich wenn es zb 2 oder 3 Videoquellen wären aufs MCA-Display bringen könnte in dem man das Display "vierteilt" so dass man auf dem Display alle Prog.-Quellen über Touch-Felder anwählen könnte... :thumbsup:
      MEINE BEZEICHNUNG LAUTET "VIERTER VON FÜNF". WIR SIND MONDEOS - WIDERSTAND IST ZWECKLOS borg
      Das will ich auch modo
      Wenn man tot ist, ist das für einen selber nicht schlimm, weil man ja tot ist ... schlimm ist es für die anderen .... genauso ist das übrigens wenn man doof ist! :D

      Dermon4 schrieb:

      Go4IT schrieb:

      Die Eingänge sind priorisiert, so kann man z.B. an Video-P1 die Rückfahrkamera anschließen. Immer wenn die ein Bild liefert, wird darauf gewechselt, so wie im Original. An Video-P2 dann z.B. ne Frontkamera und an Video-P3 einen Mediaplayer oder ein Andriod für geile Navigation, oder was weiß ich Auch Audio will ich damit schalten.


      Wenn man das ganze dann noch per "Bild im Bild" sprich wenn es zb 2 oder 3 Videoquellen wären aufs MCA-Display bringen könnte in dem man das Display "vierteilt" so dass man auf dem Display alle Prog.-Quellen über Touch-Felder anwählen könnte... :thumbsup:



      Kein Scherz übrigens, das war schon ernst gemeint. Ich hab das mit Respekt vor Go4IT's Fähigkeiten geschrieben.
      MEINE BEZEICHNUNG LAUTET "VIERTER VON FÜNF". WIR SIND MONDEOS - WIDERSTAND IST ZWECKLOS borg
      Tja, meine Fähigkeiten... :/
      also gestern mal einen Test im Auto gemacht, permanent R-Signal zusätzlich gesendet (ID 433). Im Stand alles super, konstantes Bild, selbst wenn ich nur alle paar Sekunden sende.
      Dann Motor gestartet, dabei geht das Radio ja kurz aus, bzw. wird Dunkel und danach nix mehr, bzw. nur normales Bild. Selbst mit Original R-Kamera. Also mal alles aus, etwas gewartet und das ganze nochmal, geht wieder. Hm...
      Bei laufendem Motor sieht die Sache ganz anders aus, da muss ich mind. mit 100 ms senden und selbst dabei flackert das Display ordentlich hin und her.
      Dies Signale Rückwärtsgang drin von mir, sowie Rückwärtsgang draussen vom Convers überlagern sich in gewisser weise. Wenns blöd läuft geht eines davon verloren, bzw. wird durch das andere während der Übertragung ungültig (checksum stimmt nicht). Die Überlagerung von zwei Frequenzen bringt diesen untegelmäßigen Flackereffekt, egal wie schnell ich sende.
      Falk meinte das der Adapter von Motral das stabil,hinbekommt, ich meine das es nicht ohne Gateway geht an dem ich das Signal zum Radio hin beliebig manipulieren kann. Was bei meinenm Test natürlich anders war ist, das ich von einer Software vom PC sende, die relativ hohe Latenzeiten. 100 ms sind da schon schwierig. Müsste das ganze also auch nochmal mit einer nativen Hardwarequelle versuchen.

      Also erstmal ernüchternd.
      Für den technisch interessierten (alle anderen sind hier in der Bastelstube eh falsch ;)

      Hier mal den Signalweg wie das Kamerabild ins Display kommt:

      Quellcode

      1. [ CCD (Chip auf der Kamera) ] ==> RGB-Bilddaten (digital, parallel) ==> [ MAX9217 (RGB zu LVDS wandler) ] --> RGB-Bilddaten (digital, seriell) --> [ MAX9218 (LVDS zu RGB wandler) ] ==> [ MC9S12DG128 (Bildprozessor, überlagerung der Linien und Symbole aufs Bild) ] ==> RGB-Bilddaten (digital, parallel) ==> [ ADV7179 (RGB zu FBAS wandler) ] --> Composite-Video (analog, seriell) --> [ Video-In vom MCA ] --> [ ADV7181 (FBAS zu BT656 wandler) ] ==> ITU-BT.656 Bilddaten (digital, parallel) ==> [ Display-Controller ] ==> Parallel => [ TFT-Display ]


      Wer jetzt nix verstanden hat, hier nochmal die ausformulierte Fassung davon:
      1. Auf der Kameraplatine sitzt ein CMOS-Bildsensor (CCD). Dieser wandelt das Licht in ein parallel anliegendes digitales RGB-Signal um.
      2. Seine Datenleitungen sind an einen MAX9217 (LVDS Serializer) verbunden. Dieser erzeugt aus den parallelen RGB-Daten einen seriellen Datenstrom im LVDS-Format.
      3. Dies gelangt dann über die Leitung in der Heckklappe zum Kameramodul im Kofferraum und wird darin von einem MAX9218 (LVDS Deserializer) wieder in das parallele RGB-Signal zurückkonvertiert.
      4. Das als RGB-Datenstrom übertragene, digitale Videosignal wird dann von einem als Bildprozessor programmierten MC9S12DG128 Mikrocontroller mit den berechneten Hilfslinien, Entfernungsbalken, Spiegelsymbolen usw. angereichert. -bis hierhin ist alles digital und verlustfrei-
      5. Der Mikrocontroller gibt die Daten dann als digitale RGB-Daten an einen ADV7179 weiter, welcher daraus ein analoges Composite-Videosignal erzeugt. -ab jetzt ist das Bild unscharf-
      6. Das analoge FBAS-Signal im NTSC-Format (das kennt nur 525 Zeilen von denen max 480 sichtbar sind, anstelle der 600 möglichen vom Display) wird dann über die lange Leitung bis zum Radio geführt und dort über die Video-In Buchse eingespeist.
      7. So gelangt es an den ADV7181, der das Signal zerlegt und digitalisiert. An seinem Ausgang stehen dann die Bilddaten parallel im ITU-BT.656 Format an. Dieses Format wird auch vom Mainboard-Controller (OMAP5849) generiert und ist häufig als Einspeiseformat für parallel angeschlossene Displays zu finden. Über einen Umschaltmechanismus wird dann intern entschieden ob der OMAP-Maincontroller oder der ADV-Videochip seine Daten auf diesen Bus zum Display senden darf.
      8. Das Display wandelt dann die Daten wieder in ein sichtbares RGB-Bild um ;)
      Bei diesem Signalweg, vor allem der D/A und A/D-Wandlung dürfte klar sein warum da nur Matsche im Bildschirm ankommt und kein scharfes Bild. Dabei bleibt man mit der Wahl des NTSC-Übertragungsformates auch noch weit unter den Möglichkeiten des WVGA-Displays (800x600). Andere Systeme übertragen von der Kamera per LVDS direkt in die Headunit ("Radio"), alles digital und das sieht man dann auch.

      Wer auch das jetzt nicht verstanden hat, beherzigt bitte den Satz in der Einleitung und denkt sich "wie kann man so einen Sch*** interessant finden?" pillepalle

      Go4IT schrieb:

      Dies Signale Rückwärtsgang drin von mir, sowie Rückwärtsgang draussen vom Convers überlagern sich in gewisser weise.

      Da kannst Du vermutlich drauf warten, daß ABS und ESP DTC's erzeugen. Die wollen schon genau wissen, ob vor oder zurück. :D
      Gruß aus Erfurt

      Schon der dritte Ford und der Fahrer wird nicht schlau draus!
      Danke fürs mitdenken, aber ich arbeite hier nur auf MM-CAN. Die ID 433 wird vom IPC nicht in den MS- oder HS-CAN vermittelt, nur umgekehrt.
      Das Problem ist eher das beim ständigen auslösen von Kollissionen im Bus die Errorcounter der Schnittstellen hoch gehen und irgendwann ein zeitweises oder längerfristiges deaktivieren zur Folge haben könnten.
      Kurzer Zwischenstand im Projekt:

      Die von mir bestellten "Videoquellen" sind da. Hab mir zwei billige Rückfahrkameras gekauft, sowie einen VGA-zu-FBAS Umsetzer um genügend Quellen für den Test der Umschalter zu haben. Eine Cam hab ich mal probeweise angeschlossen und ich muss sagen das das Bild schon echt zucker ist. So sollte das von der Originalen mal sein. VIEL schärfer und klarer, wenn auch etwas übersteuert. Also mit der richtigen Quelle ist auch das Bild, selbst analog, schon gut. Da hat Ford wohl einfach nur nen beschissenen CCD-Sensor für seine Cam verwendet.

      Weiterhin habe ich mir mehrere Video-Switch ICs bestellt die auch eingetroffen sind. Zwar ließe sich das auch mit einfachen Analogschaltern realisieren (z.B ein CD4052) aber dann benötigt man Puffer und div. weitere Bauteile damit das Signal durchleitbar ist und nicht verzerrt, verrauscht oder sonst irgendwie negativ beeinflußt wird (was ja von hause aus schon schlecht genug ist). Daher habe ich mich für spezialisierte ICs von MAXIM, bzw. LINEAR entschieden. Jeweils 4-Fach Umschalter mit Buffer.

      Grundsätzlich werde ich auch einen Audio-Umschalter mit vorsehen. Der ist billig zu realisieren.

      Werde die Tage den ersten Testaufbau machen. Erstmal nur den "Analogteil", sprich mit manueller Umschaltung der Quelle ohne Mikrocontrollersteuerung. Bericht mit Bildern folgt dann.
      So, der Umschalter wäre schonmal fertig :) Realisiert mit einem MAX4311 (war jetzt von allen mir getesteten Chips der Beste und unkomplizierteste, wenn auch etwas schwierig zu beschaffen, aber das ist im allgemeinen mit den Video-ICs so...)

      So ein Prototyp auf dem Steckbrett schaut halt immer etwas chaotisch aus:


      Ganz links ist nur ein kleiner Spannungswandler für 12V auf 5V. Dann kommt links das Cynchkabel mit dem gelben Stecker in Richtung Radio (Video-Ausgang der Schaltung), das nächste, rote ist nur Dummy da hätte ich z.B. noch meinen VGA-zu-FBAS vom Laptop anschließen können, und dann kommt (weiß) das Signal der Rückfahrkameras und dann (schwarz, rot) die der Zusatzkameras. Der Hauptprotagonist sitzt auf dem grünen SMD-Adaptersockel. Drumherum ein paar wenige, aber benötigte passive Bauteile zur Entstörung und Pegelanpassung. Umgeschaltet wird einfach mit den zwei Tastern rechts. Diese Funktion wird in der nächsten Fassung ein Mikrocontroller übernehmen.

      Meine Versuchsvideoquellen waren neben der Original-Rückfahrkamera noch zwei weitere Billig-Rückfahrkameras:


      Zum Glück hatte ich mir damals beim nachrüsten des MCA-Plus den Videoverbinder vom Pigtail des Radios zur Videoleitung des RFK-Moduls ins Handschuhfach gelegt. So komm ich da für Tests prima dran:

      (der Rest Gemülle da drin ist MM-CAN Loop und meine Webasto TC3. Irgendwo hab ich mal gehört das man in so ein Handschuhfach auch Papiere und Warnwesten und all so zeugs reinlegen kann. Pah! So ein Unsinn, das ist doch eine Optimale Projektumgebung ;)

      Und hier nun das verwackelte Video vom ersten Test (die Flackerer am Anfang kommen von meiner Rückfahrkamera. Jaja, ich Arsch, hab ich damals doch gedach das ein wenig einfetten des Steckers im Kofferraumdeckel reicht. Nun kann ich den ganzen Rotz wieder ausbauen und verlöten. Naja, wer nicht hören will...)



      Die Qualität ist Top und umschalten geht ohne Flackern und ohne Neusynchronisation da der Chip immer in der Austastzeit des Signals schaltet. Jetzt geht ich an die Steuerung. Mit so einem 4-Fach umschalter könnte man natürlich auch 4 Kameras am Auto platzieren (vorn/hinten, rechts/links). Für ein echtes Surroundview bräuchte man jedoch einen leistungsfähigen DSP für Videoverarbeitung. Kein Hexenwerk, aber auch nicht trivial ;)

      Go4IT schrieb:

      (der Rest Gemülle da drin ist MM-CAN Loop und meine Webasto TC3. Irgendwo hab ich mal gehört das man in so ein Handschuhfach auch Papiere und Warnwesten und all so zeugs reinlegen kann. Pah! So ein Unsinn, das ist doch eine Optimale Projektumgebung


      Irgendwann fackelst du die Möhre einfach ab :D
      Gruß Tom :fahrenlenkrad:

      ____________________________________________________________
      Dieser Beitrag wurde bereits 1.694.000 mal editiert, zuletzt von »digdog« (Heute, 01:96)
      Erinnert mich immer so ein wenig an "Robbi, Tobbi und das Fliewatüüt"...
      OH
      Die schnellste Verbindung zwischen zwei Punkten ist eine Gerade.
      Die von den meisten Fahrern am wenigsten beherrschte Strecke zwischen zwei Geraden ist eine Kurve.
      Was das heißt?

      Geradeaus sind wir alle schnell !!!

      Achtung! Beiträge können Ironie enthalten! Ironie unterliegt nicht der Kennzeichnungspflicht!

      Meine Beiträge in diesem Forum geben ausschließlich meine persönlichen Meinungen und Wissensstände wider.

      Go4IT schrieb:

      Jo, wer das Fliewatüt ist ist klar, bleibt nur die Frage wer ist "Robbi" und wer "Tobbi" ?


      Gruß Tom :fahrenlenkrad:

      ____________________________________________________________
      Dieser Beitrag wurde bereits 1.694.000 mal editiert, zuletzt von »digdog« (Heute, 01:96)
      Wenn ich dich richtig verstehe werkelst du noch am Aufmotzen von einem MCA mit dem Video-Chip mit dem Vogelfutter -- Richtig ?
      Könnte man aus einem NX auf dem vFL eigentlich die Displayplatine in ein MCA stecken ?
      Wären die soweit baugleich ?
      Danke an UCDS für die 163 PS :thumbsup: