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
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.

Ich hab mir jetzt mal den Videochip (ADV7181) und das zugehörige Hühnerfutter von der im Datenblatt beiliegenden typischen Aufbau bestellt. Das werd ich einfach mal auf das MCA löten was ich hier noch rumliegen hab. Vielleicht bekomm ich das tatsächlich hin ein Standard-MCA mit einem Videoeingang nachzurüsten Versuch macht kluch...

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:

[ 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:

• Auf der Kameraplatine sitzt ein CMOS-Bildsensor (CCD). Dieser wandelt das Licht in ein parallel anliegendes digitales RGB-Signal um.
• Seine Datenleitungen sind an einen MAX9217 (LVDS Serializer) verbunden. Dieser erzeugt aus den parallelen RGB-Daten einen seriellen Datenstrom im LVDS-Format.
• 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.
• 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-
• 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-
• 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.
• 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.
• 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

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

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

Baugleich sind die Displays nicht, wodurch mit hoher Wahrscheinlichkeit ein zusammenwürfeln scheitert. Aufgrund der Firmware.

Es ist aber auch ein sehr theoretischer Ansatz, denn wer würde von einem MCA schon nur das Display nehmen...