CAN-Bus Filter Modul

  • Ich bastele gerade an einem CAN-Bus Repeater, welchen ich als Filter nutzen möchte. Das erste Ziel wäre den Videoeingang vom MCA-Plus dauerhaft zu aktivieren, indem man dem Radio die Nachricht ID 433 sendet und darin D3.2 auf 1 setzt. Dazu muss der Repeater grundsätzlich alle Nachrichten vom Radio zum Auto und umgekehrt durchlassen. Wenn das klappt kann man untersuchen wie sich das Radio verhält, wenn man die ID mit dem R-Signal sendet und sich ein geeignetes Ereigniss dafür überlegen. Im einfachsten Fall erstmal per Taster.


    Für den Versuchsaufbau habe ich auf einem Steckbrett einen Arduino Nano und zwei CAN-Shields mit MCP2515 Controller und TJA1050 Transceiver drauf zusammengebaut. Den MM-CAN hatte ich ja schon beim verlegen des Rückfahrkamerakabels am Radio aufgetrennt und ins Handschuhfach verlegt und mit einem Loop-Stecker versehen. So komme ich bequem dran und kann bei Bedarf den Normalzustand wiederherstellen.


    Im Testaufbau habe ich den Bus zum Radio hin terminiert, zum Fahrzeug hin nicht. Die Software für den Arduino besteht aus einer CAN-Bus Lib und wenigen Zeilen Code. Immer wenn der MCP eine Nachricht vollständig empfangen hat, löst er einen Interrupt aus und zieht seine /INT Leitung auf Low. Das wiederrum erkennt die Software, liest die Nachricht via SPI aus und schreibt sie umgehend an das andere Interface. Das gleiche in der anderen Richtung.


    Die Schaltung betreibe ich zunächst mit einem 5V Adapter im Zigarettenanzünder. Zunächst funktionierte die Schaltung einwandfrei, während der Fahrt verlor das Radio aber leider jede Minute den Kontakt und verschwand aus dem Convers. Ebenso setzte sich die Klima ständig zurück.


    Schade, da muss ich wohl noch weiter tüfteln... so wie es aussieht gehen Nachrichten verloren. Und das obwohl auf dem MM-CAN vergleichsweise wenig los ist. Besonders die Nachrichten vom Radio zum Fahrzeug sind oft langsam und selten. Auch geht es da ja mit gemütlichen 125kbaud auf dem CAN zu Sache. Keine Ahnung wo jetzt das Problem liegt. Vielleicht in der Lib oder der Art der Ansteuerung.

  • Ichbzab so einen Adapter in Betrieb. Es gibt gelegentliche Verwirrung was Vorwärts und Rückwärts Fahrt angeht beim Navi. Zudem verliert die Klima gelegentlich ihre Einstellung. Mal 3 Mal hintereinander, dann ist wieder Monate Ruhe.

  • Soo, nach anfänglichen Rückschlägen kann ich nun auch einen Erfolg melden! 8o


    Wie man es immer so denkt, mal schnell was zusammenkleistern, ist ja schon tausendfach gemacht worden, nicht lange nachdenken, wird schon laufen - Pöööh, nix iss! Also musste ich mich doch gaaanz tief reinknien und alles bis auf Signalebene mit DSO und Logicanalyzer debuggen, Libs umschreiben, Datenblätter schmökren und stundenlang Code durchwühlen. Aber ich hab mich reingebissen und es auch geschafft und da bin jetzt auch ein bischen stolz auf mich :rolleyes:


    Der Filter läuft, wenn aktuell auch nur als einfaches 1zu1 Gateway ohne irgendwelche Datenmanipulation. Ich kann damit CAN-IDs mit bis zu 10 ms Periode und nur ca. 1-2ms Latenz bidirektional routen, habe noch jede Menge Zeit im Arduino für die Signalverarbeitung.


    Der Aufbau ist trivial und mit reinen "Standardmitteln":

    - Einem Arduino Nano (aus China, für 3,-€)
    - Zwei MCP2515-Shields (auch aus China, für insgesamt 5,-€)
    - Einem getakteten Spannungsregler mit Entstördrossel, Überspannungs-Varistor und Kurzschluss/Cranking-Supressordiode für 8,-€
    - Ein Steckbrett und ein paar Dupont-Leitungen.


    Das ganze könnte man sicher noch günstiger machen, wenn man in größeren Mengen Platinen herstellt und anstelle der externen CAN-Controller gleich einen STM32 mit zwei On-Chip Controllern hernimmt, dann braucht man nur die externen CAN-Treiber. Aber darum kümmere ich mich später mal, jetzt gehts erstmal um die Funktion.


    Noch keine Gedanken habe ich mir über das Ein- Ausschalten des Filters gemacht. Ich denke ich werde das im üblichen CAN-Modul Stil machen. Das heißt, geschaltetes Bordnetz. Der Filter muss ja nur laufen wenn sich das Radio aktiviert, oder die Klima gebraucht wird. Durch den im Arduino enthaltenen Bootloader ist das beim Start noch zu langsam, aber das kann ich lösen indem ich diesen rausprogrammiere. Dann startet der Atmega innerhalb weniger Mikrosekunden und verhält sich wie jedes andere CAN-Modul im Mondeo. Einen besonderen Sleepmodus brauche ich glaube ich nicht, denn auf dem MM-CAN Bus ist eigentlich immer was los, auch wenn das Radio aus ist.


    Filtern/Manipulieren tue ich derzeit noch nichts, ich wollte erst sicher sein das es stabil läuft. Als nächstes würde ich dann mal einen Video-Test machen, sprich das Signal einer Zubehörkamera am Videoport des MCA einspeisen und auf dem CAN-Bus das Rückfahrsignal in Richtung Radio simulieren. Das müsste eigentlich das Videobild dauerhaft einblenden. Ein Problem dabei ist, das sobald man beim dargestellten Videobild eine Taste am Radio oder der Klima betätigt, das Bild verschwindet und erst beim nächsten einlegen des Rückwärtsganges wieder kommt. Es gibt keine Taste mit der man das Bild geziehlt wieder einblenden kann. Ich werde mal prüfen wie das Radio reagiert, wenn man ihm immer wieder das erneute einlegen des Rückwärtsganges vorgaukelt, anstelle einach nur das R-Flag permanent zu senden.


    Naja und neben dem fallen mir noch weitere Spielerein mit dem Filter ein. Natürlich zum hacken, denn das Modul weiss ja nun welche Nachricht von wem erzeugt wurde. Das will ICH natürlich auch wissen :-) also muss ich mir das entweder über die Serielle ausgeben lassen (hmmm.. das könnte etwas langsam werden, weil die ja max. 115kbaud macht) oder auch eine SD-Card protokollieren lassen.

  • Mit dem Einblenden des Bildes: Wenn das Video Signla unterbrochen wurde und dann wieder kommt, kommt auch das Bild wieder. Eventuell könnte hier ein einfacher Unterbrechen Taster in der Video Leitung diesen "zurückholen" Knopf realisieren.

  • Ok, da fehlt mir noch etwas die Praxis. Bislang habe ich als einzige Videoquelle ja nur die Rückfahrkamera und deren Videosignal wird ja durch das Modul bestimmt. Mal sehen wie sich das mit einer anderen, dauerhaft sendend Quelle verhält...

  • So, habs heut testen können. Wenn ein Videosignal anliegt UND das R-Signal gesendet wird (Bit 1 in Byte D3 von ID 0x433 = 1), dann schaltet das MCA auf die Quelle um.


    Beim ersten mal, nach einschalten des Radios kommt dann die Meldung von wegen Aufpassen und so im Display. Das macht also (leider) das MCA.


    Sende ich R und entferne die Videoquelle, schaltet das MCA sofort wieder zurück auf Menüanzeige. Das passiert mit mit der Originalkamera, weil das RFK-Modul die Kamera abschaltet, wenn der Rückwärtsgang nicht mehr auf dem MS-CAN anliegt. Um also dauerhaft hinten raus gucken zu können müsste man auch einen CAN-Filter vor das RFK Modul setzen. Das Modul zeigt ja auch ohne Daten vom PDC das Bild an. Kann man leicht selbst testen :-)


    Sende ich das Videosignal und nehme das R weg, dann schaltet das MCA nach ca. 12 Sekunden wieder zurück auf Menü.


    Leider hat bei meinen Tests meine Billig-Nachrüst-RFK den Geist aufgegeben. Das Bild wurde immer dunkler, bis es fast schwarz war. Keine Ahnung was das ist, aber die Orginalkamera funktioniert nach wie vor einwandfrei. Muss also an dem Billigteil liegen...


    Werde mir jetzt mal Gedanken machen womit ich sonst noch so ein FBAS senden kann.

  • Werde mir jetzt mal Gedanken machen womit ich sonst noch so ein FBAS senden kann.


    Sowas? HDMI von Notebook rein und Video-Out raus.
    http://www.dx.com/de/p/hdmi-to…ko0wodt_YJBw#.WV6HP3FCSM8


    Oder so, wenn da VGA vorhanden ist an einem älteren Notenbock.
    http://www.dx.com/de/p/pc-vga-…wW0wod2CUBSw#.WV6IRXFCSM8


    Ob die Darstellung/ Bildgröße oder sonstiges paßt, kann ja egal sein, geht ja nur um die Signaleinspeisung. :)

    Gruß aus Erfurt


    Schon der dritte Ford und der Fahrer wird nicht schlau draus!