Mit diesem Projekt wollte ich eigentlich die Funktionalität meines Autos verbessern. Der darin ab Werk verbaute "Geschwindigkeitslimit-Assistent" von Mercedes ist leider derart schlecht und dilettantisch konstruiert, dass man ihn eigentlich nur abgeschaltet ertragen kann - nicht wirklich zweckmäßig für etwas, das man eigentlich für sinnvoll erachtet und das tatsächlich einiges an Geld gekostet hat. Während einer normalen Fahrt erzeugt dieser praktisch Fehlalarme am laufenden Band - für jemanden mit meinem konservativen Fahrstil kommt dieser ohne Übertreibung auf eine Fehlalarm-Rate von 95%.
Ich möchte gewarnt werden -gerne deutlich und akustisch- wenn ich dusseligerweise zu schnell bin und ganz offensichtlich ein Geschwindigkeits-Schild übersehen habe, aber doch bitte nicht, wenn ich schon dabei bin, die Geschwindigkeit auf das geforderte Maß zu reduzieren - und schon gar nicht alle 15 Sekunden über die nächsten 10km, wenn die Kamera mal ein Schild falsch erkannt hat. Das ist aber leider genau das, was dieser "Geschwindigkeitslimit-Assistent" von Mercedes macht...
Die verbaute Kamera in dem Auto ist dabei aber gar nicht das Problem, sondern alleine die bemerkenswert intelligenzlose Art und Weise, mit der die Software-Ingenieure von Mercedes deren Signale und die anderen Fahrparameter auswerten und miteinander verknüpfen. Einfach mal für 10ct Nachdenken hätte das System so viel besser machen können, ohne dass es teurere Hardware benötigt hätte.
Wie auch immer, mein Plan war jedenfalls, das System von Mercedes leise zu stellen und mir stattdessen mein eigenes akustisches Warnsignal zu erzeugen. Die dafür nötigen Signale (erkanntes Geschwindigkeitslimit, aktuell gefahrene Geschwindigkeit, in der Cruise-Control eingestellte Geschwindigkeit und Betätigung der Bremse) werden ja in der Cockpit-Einheit angezeigt - und (so war zumindest meine Vermutung) werden über den CAN-Bus dorthin übertragen. Mein System sollte diese Werte aus der CAN-Kommunikation mitlesen, über eine eigene intelligente Entscheidungs-Logik die Parameter verknüpfen und entsprechend ein Signal erzeugen, das bei einer offensichtlichen Geschwindigkeitsübertretung in einem separaten Sound-Modul einen Warnton erzeugt.
Leider hat sich bei Messungen mit meinem CAN-Sniffer herausgestellt, dass einige der notwendigen Parameter nicht über den CAN-Bus sondern offensichtlich über ein separates Video-Interface übertragen werden. Mein schöner Plan ging dadurch leider in die Hose, aber die Hardware ist gebaut, funktional und schön klein...
Als Rechner kommt auf der Hardware ein PIC18F13K50 zum Einsatz. Er bietet (neben vielen anderen) die notwendigen Peripherien SPI- und UART-Interface. Diese könnte man zwar mit etwas Aufwand auch per bit-banging erzeugen und damit einen weniger umfangreichen Prozessor verwenden, für dieses Projekt wollte ich aber so wenig wie möglich in diese Tiefen hinabsteigen und stattdessen flexibel bleiben. Über SPI ist ein MCP2517 CAN-FD-Controller angeschlossen, der über einen TCAN1051 Transceiver an den Bus geht. Prinzipiell wäre das System also auch für CAN-FD-Busse geeignet.
Als Signal-Ausgänge gibt es zum einen die GPIO-Schnittstelle "Sig-Out", über die in meinem geplanten System das Soundmodul gesteuert worden wäre. Zum anderen wurde noch ein Rx/Tx-UART Interface als Diagnoseschnittstelle angebaut, sowie ein reiner Tx-UART über Ext-IF, über den ich beispielsweise noch andere Anzeigegeräte hätte anschließen können.
Die Spannungsversorgung wird über den Schaltregler TPS57140 bereitgestellt. Dieser ist absichtlich so großzügig (bis 1,5A) ausgelegt, weil geplant war, damit auch das Soundmodul über Sig-Out und die evtl. zusätzliche Anzeigeeinheit über Ext-IF zu versorgen.
Schaltplan des CAN-Trackers
Die Firmware bietet natürlich nicht den Funktionsumfang des geplanten Systems - siehe obige Begründung für das Scheitern des Projekts. In dem aktuellen Stand sind zwar alle Basisfunktionen des Systems implementiert, es wird aber einfach nur eine einzelne CAN-ID (0x30B: Uhrzeit in Minuten/Sekunden) mitgelesen und die Werte über den UART ausgegeben.