Smart 451 CDI Daten über CAN-Bus auslesen

[local stone]

Hallo liebe Smart-faszinierte...

Ich habe ein kleines Projekt, das ich endlich mal machen will.

Über OBD2 mit einem CAN-Adapter Daten auslesen und Filtern (Füllstand Tank, Öltemp, Kühlflüssigkeittemp usw).

Dazu folgende Bauteile:

 

https://www.amazon.de/AZDelivery-MCP2515-Shield

https://www.amazon.de/gp/product/B081N7G2BR/ref=ewc_pr_img_1?smid=A3LR51RN935ZZX&psc=1

Einen Arduino habe ich bereits.

Aufbau:

----------------------------------------------------------------------------

Verbindung des MCP2515-Moduls mit dem OBD2-Port

OBD2-Port	MCP2515-Modul
Pin 6 (CAN-H)	CAN-H
Pin 14 (CAN-L)	CAN-L
Pin 4 (GND)	GND

-----------------------------------------------------------------------------

 

 

Ist das bei dem Smart technisch möglich? Ich muss nur das wissen und vielleicht ein paar nützliche Tipps falls das jemand schonmal gemacht hat.

 

Danke!

[450-3]

Ja, ist möglich. Beim 451 ist im Gegensatz zum 450 ja praktischerweise der CAN-Bus gleich über die OBD-Dose erreichbar.

 

Wenn du die Nachrichten-IDs mit den Werten noch nicht kennst, ist die Analyse mit einem Arduino aber recht mühsam, da man von der Masse der Daten sofort erschlagen wird.

Ich habe mir dafür eine Lösung mit einem RaspberryPI Zero W und diesem Adapter (KLICK) gebaut, als WLAN AccessPoint konfiguriert und eine Powerbank drunter geschnallt. Zugriff dann drahtlos mit dem Notebook über SSH. 

Der Adapter wird von Linux unterstützt und man kann z.B. die CAN-Tools verwenden.

Damit geht die Auswertung, in welchen Nachrichten sich die gesuchten Werte verstecken, viiiiel einfacher und schneller 

 

 

Vieles von dem, was über die Diagnose als Parameter ausgelesen werden kann, liegt aber auch gar nicht direkt auf dem CAN-Bus. Für diese Werte müsstest du dann noch zusätzlich das Diagnoseprotokoll emulieren, um die Parameter aktiv beim Steuergerät abzufragen, so wie es auch das Diagnosegerät macht.

Das Diagnoseprotokoll selbst läuft beim 451 dann aber auch wieder auf dem CAN-Bus, kann also ebenfalls recht einfach analysiert werden, wenn du dich parallel zum Diagnosegerät an den Bus klemmst und den Datenverkehr beobachtest.

 

bearbeitet 28. November von 450-3

[local stone]

vor 7 Minuten schrieb 450-3:

Ja, ist möglich. Beim 451 ist im Gegensatz zum 450 ja praktischerweise der CAN-Bus gleich über die OBD-Dose erreichbar.

 

Wenn du die Nachrichten-IDs mit den Werten noch nicht kennst, ist die Analyse mit einem Arduino aber recht mühsam, da man von der Masse der Daten sofort erschlagen wird.

Ich habe mir dafür eine Lösung mit einem RaspberryPI Zero W und diesem Adapter (KLICK) gebaut, eine Powerbank drunter geschnallt und als WLAN AccessPoint konfiguriert. Zugriff dann drahtlos mit dem Notebook. 

Der Adapter wird von Linux unterstützt und man kann z.B. die CAN-Tools verwenden.

Damit geht die Auswertung, in welchen Nachrichten sich die gesuchten Werte verstecken, viiiiel einfacher und schneller 

 

 

Vieles von dem, was über die Diagnose als Parameter ausgelesen werden kann, liegt aber auch gar nicht direkt auf dem CAN-Bus. Für diese Werte müsstest du dann noch zusätzlich das Diagnoseprotokoll emulieren, um die Parameter aktiv beim Steuergerät abzufragen, so wie es auch das Diagnosegerät macht.

Das Diagnoseprotokoll selbst läuft beim 451 dann aber auch wieder auf dem CAN-Bus, kann also ebenfalls recht einfach analysiert werden, wenn du dich parallel zum Diagnosegerät an den Bus klemmst und den Datenverkehr beobachtest.

 

Das nenne ich mal informativ!. Mega!. Ich habe noch einen esp8266. Müsste mit dem ja auch gehen weil er auch wlan hat, oder sind die Datenmengen so groß? Welche Libary nutzt du auf dem Raspi, bzw wie funktioniert es im Detail? Dann bestelle ich das OBD Kabel oder vielleicht ein günstigeres und den Can-bus Adapter.

 

Für die Analyse gibt es ja dann relativ praktische Tools, die die Auswertung erleichtern.

[450-3]

Auf dem PI Zero (nicht die Pico-Version mit dem Microcontroller sondern nur der etwas geschrumpfte Standard-PI) läuft bei mir raspbian Linux mit dem Paket "can-utils".
Damit gibt es dann ein paar Kommandozeilen Tools zur Auswertung, z.B. den cansniffer, der aus den Tausenden Nachrichten pro Sekunde schön übersichtlich nur die anzeigt, die sich wirklich geändert haben.

Wenn du also wissen willst, ob der Status der Klimaanlage auf dem Bus verfügbar ist, startet man das Tool, schaltet die Klima einmal ein und aus und sieht sofort, welche Nachrichten sich geändert haben und interessant sein könnten.

 

Es gibt auch Tools, um Nachrichten zu erzeugen und dann zu sehen was passiert. Damit habe ich am Kombiinstrument die verfügbaren Symbole in der Ganganzeige gefunden, mit einem Shellscript, dass einfach über zwei Schleifen alle Bits durchprobiert hat. 

Das kann man natürlich auch alles irgendwie in den Arduino programmieren aber mir fehlt da die Flexibilität um schnell mal etwas auszuprobieren. Und warum sich unnötig Arbeit machen, wenn es die Tools schon gibt.

 

Sobald dann alle Infos bekannt sind und es an die Umsetzung des Projekts geht, nehme ich natürlich auch einen Arduino oder einen ESP. Allein schon weil der PI Zero mit seinem fetten Betriebssystem für die meisten Projekte total überdimensioniert ist und auch nicht echtzeitfähig.

 

bearbeitet 28. November von 450-3

[local stone]

vor 1 Minute schrieb 450-3:

Auf dem PI Zero (nicht die Nano-Version mit dem Microprozessor sondern nur der etwas geschrumpfte Standard-PI) läuft bei mir raspbian Linux mit dem Paket "can-utils".
Damit gibt es dann ein paar Kommandozeilen Tools zur Auswertung, z.B. den cansniffer, der aus den Tausenden Nachrichten pro Sekunde direkt nur die anzeigt, die sich wirklich geändert haben.

Wenn du also wissen willst, ob der Status der Klimaanlage auf dem Bus verfügbar ist, startet man das Tool, schaltet die Klima einmal ein und aus und sieht sofort, welche Nachrichten sich geändert haben und interessant sein könnten.

Es gibt auch Tools, um Nachrichten zu erzeugen und dann zu sehen was passiert. Damit habe ich am Kombiinstrument die verfügbaren Symbole in der Ganganzeige gefunden, mit einem Shellscript, dass einfach über zwei Schleifen alle Bits durchprobiert hat. 

Das kann man natürlich auch alles irgendwie in den Arduino programmieren aber mir fehlt da die Flexibilität um schnell mal etwas auszuprobieren. Und warum sich unnötig Arbeit machen, wenn es die Tools schon gibt.

 

Sobald dann alle Infos bekannt sind und es an die Umsetzung des Projekts geht, nehme ich natürlich auch einen Arduino oder einen ESP. Allein schon weil der PI Zero mit seinem fetten Betriebssystem für die meisten Projekte total überdimensioniert ist und auch nicht Echtzeitfähig.

Cool, leider habe ich aktuell nicht so viel Zeit, habe eine Petition gegen 30 auf der Bundesstraße gestartet und bin ziemlich eingebunden (6800 Unterschriften bis jetzt).

Mein Smart mag 30 nicht. 40 oder 50 war ihm doch lieber. Vor allem weil der Spritverbrauch steigt durch das ganze Stop and Go.

 

Ich werde auf dich zurückkommen. Ich glaube ich habe sogar nen raspi 4 noch da. Dann hole ich mir den can-hat für raspi und den für den ESP. Macht das Sinn?

 

Danke für die Hilfe

[450-3]

Das kommt ja wie immer drauf an 

Ich habe mal einen Controller für das Kombiinstrument des 450 mit einem kleinen Arduino gebaut. Die Nachrichten mussten mit 10ms getacktet sein, sonst gingen schnell die Warnlampen an. War kein Problem aber eben auch nicht so komplex.

 

Wenn du z.B. einen Datenlogger bauen willst, der dir bestimmte Werte auf eine SD Karte schreibt und vielleicht noch ein paar Sachen berechnet, könnte es aber schon wieder knapp werden, da die kleinen Arduinos nur einen einzelnen, im Vergleich zum ESP recht langsamen Prozessorkern haben, der das Timing für CAN und SD zusätzlich zu deinem Code allein schaffen muss.

 

Der ESP8266 hat da schon mehr Dampf, aber nur wenn WLAN deaktiviert ist, sonst geht ihm schnell die Luft aus.

Damit habe ich einen Feinstaubsensor mit einer komplexen Alarmfunktion mit ESPHome gebaut. Das ging eine Weile gut aber irgendwann war der Code dann zu rechenintensiv und das WLAN wurde instabil und es gingen keine OTA-Updates mehr. Musste dann auf den ESP32 umsteigen und damit läuft wieder alles wunderbar.

 

Den ESP32 gibt es mit zwei Kernen aber da musst du dich selbst darum kümmern, dass dein Code auch auf beiden Kernen ausgeführt wird. Von allein passiert das nicht.

 

Wenn es aber nur ein temporäres Projekt ist, könntest du auch einfach probieren, alles direkt auf dem Raspbery zu machen. Der Adapter von Waveshare ist kompatibel zu socketcan und damit dürfte es für fast alle Programmiersprachen irgendeine Anbindung geben. Muss dann halt nur immer booten und Linux ist ja auch nicht für jeden so der Hit 

 

Der Arduino hat den Vorteil, dass es schon tonnenweise Beispiele und Libraries für alles Mögliche im Netz gibt. Je weiter man sich vom De-facto-Standard weg bewegt, desto holperiger wird es.

 

bearbeitet 28. November von 450-3

[local stone]

vor 2 Stunden schrieb 450-3:

Das kommt ja wie immer drauf an 

Ich habe mal einen Controller für das Kombiinstrument des 450 mit einem kleinen Arduino gebaut. Die Nachrichten mussten mit 10ms getacktet sein, sonst gingen schnell die Warnlampen an. War kein Problem aber eben auch nicht so komplex.

 

Wenn du z.B. einen Datenlogger bauen willst, der dir bestimmte Werte auf eine SD Karte schreibt und vielleicht noch ein paar Sachen berechnet, könnte es aber schon wieder knapp werden, da die kleinen Arduinos nur einen einzelnen, im Vergleich zum ESP recht langsamen Prozessorkern haben, der das Timing für CAN und SD zusätzlich zu deinem Code allein schaffen muss.

 

Der ESP8266 hat da schon mehr Dampf, aber nur wenn WLAN deaktiviert ist, sonst geht ihm schnell die Luft aus.

Damit habe ich einen Feinstaubsensor mit einer komplexen Alarmfunktion mit ESPHome gebaut. Das ging eine Weile gut aber irgendwann war der Code dann zu rechenintensiv und das WLAN wurde instabil und es gingen keine OTA-Updates mehr. Musste dann auf den ESP32 umsteigen und damit läuft wieder alles wunderbar.

 

Den ESP32 gibt es mit zwei Kernen aber da musst du dich selbst darum kümmern, dass dein Code auch auf beiden Kernen ausgeführt wird. Von allein passiert das nicht.

 

Wenn es aber nur ein temporäres Projekt ist, könntest du auch einfach probieren, alles direkt auf dem Raspbery zu machen. Der Adapter von Waveshare ist kompatibel zu socketcan und damit dürfte es für fast alle Programmiersprachen irgendeine Anbindung geben. Muss dann halt nur immer booten und Linux ist ja auch nicht für jeden so der Hit 

 

Der Arduino hat den Vorteil, dass es schon tonnenweise Beispiele und Libraries für alles Mögliche im Netz gibt. Je weiter man sich vom De-facto-Standard weg bewegt, desto holperiger wird es.

 

Als angehender Fachinformatiker ist Linux kein Problem. Hatte paar Smarthome Projekte, Trafficfilter, Visualisierung etc. Bin aber leider noch nicht allzu tief in der Materie drinnen. Ich würde mich einfach bei dir melden wenn alles soweit ist.

[450-3]

Na dann bist du ja schon mal gut gerüstet. 

Kannst mich gerne kontaktieren. Es sind auch noch ein paar andere hier in dem Thema drin, da bleibt dann hoffentlich keine Frage offen 

 

bearbeitet 28. November von 450-3

[Petros_T]

Das hab ich auch schon hinter mir, der Smart ist ein super Auto um den Canbus und das UDS Protokoll besser zu verstehen. Da Wenige Steuergeräte und sehr wenige CAN iDs.

[local stone]

Am 1.12.2024 um 21:39 schrieb Petros_T:

Das hab ich auch schon hinter mir, der Smart ist ein super Auto um den Canbus und das UDS Protokoll besser zu verstehen. Da Wenige Steuergeräte und sehr wenige CAN iDs.

Woher sind die auf den Bildern?

[Funman]

Hat Petros selbst gemacht. 

[local stone]

Am 6.12.2024 um 19:25 schrieb Funman:

Hat Petros selbst gemacht. 

Ah ja habe es jetzt auch gesehen 🙂 

[local stone]

Okay ich finde das Pinout Can H/L nicht für den OBD Stecker, wo kann ich das finden?

[450-3]

vor 25 Minuten schrieb local stone:

Okay ich finde das Pinout Can H/L nicht für den OBD Stecker, wo kann ich das finden?

 

Sollte laut Schaltplan auf Pins 6 (High) und 14 (Low) anliegen, wie im Standard vorgesehen. In der Wikipedia gibt es ein Bildchen mit den Pinnummern,

[local stone]

Gerade eben schrieb 450-3:

 

Sollte laut Schaltplan auf Pins 6 (High) und 14 (Low) anliegen, wie im Standard vorgesehen. In der Wikipedia gibt es ein Bildchen mit den Pinnummern,

Habe gar nicht daran gedacht, dass das standartisiert ist, danke dir.

Macht jetzt natürlich alles Sinn jetzt

[local stone]

Ich habe es geschafft die CAN-Daten auszulesen, es funktioniert super! Jetzt ist nur die Frage... gibt es eine Sammlung der CAN-IDS oder eine Anleitung wie die Hex-Werte funktionieren?
Wenn keine offizielle, dann vielleicht eine inoffizielle?

[450-3]

vor 12 Stunden schrieb local stone:

gibt es eine Sammlung der CAN-IDS oder eine Anleitung wie die Hex-Werte funktionieren?
Wenn keine offizielle, dann vielleicht eine inoffizielle?

 

Offiziell ist nichts veröffentlicht, soweit ich weiß. Ganz großes Betriebsgeheimnis 

Für den 451 gibt es aber einiges im Netz, z.B. hier oder hier  oder hier. Auch wenn nicht alles 1:1 zu deinem Modell passt, kann man sich bei den Projekten vieles abschauen, was die Auswertung der Nachrichten betrifft.

 

Die Verarbeitung ist eigentlich immer gleich.

Zahlenwerte sind entweder in 8 oder 16 Bit Blöcken kodiert, je nachdem wie hoch die Präzision sein soll. Manchmal muss noch ein Offset auf den Wert gelegt werden, häufig bei Temperaturen, also z.B. x - 40 um den tatsächlichen Messwert zu erhalten.

Boolesche Werte werden platzsparend blockweise in Bytes gepackt, hier für die Kontrollleuchten im KI und Aktivierungen im SAM, die das Motorsteuergerät vom 450 in Nachricht 0x190 Byte 2 verschickt.

 

 

Ich habe eine Sammlung von Nachrichten IDs für den 450, das meiste hat sich aber beim 451 geändert. 

 

Um herauszufinden, wo sich ein Wert versteckt, finde ich es immer am einfachsten, während der Beobachtung irgendwie eine drastische Änderung zu provozieren. Wenn z.B. ein Sensorwert gesucht ist, kann man den Stecker schnell mal abziehen. Dann kommt vielleicht irgendwo in einer Nachricht plötzlich ein Fehlerwert "FF" oder "FE" und Bingo! Parameter gefunden. Fön und Kältespray sind auch manchmal hilfreich.

Um herauszufinden welche Steuergeräte welche Nachrichten verschicken, mal die Sicherung der Versorgungsspannung ziehen und schauen, welche Nachrichten verschwinden.

Damit lässt sich mit einfachen Mitteln schon viel erreichen und kaputt kann man so eigentlich auch nichts machen, außer ein paar Fehler im Fehlerspeicher zu produzieren. 

 

Selbst so Spezialitäten wie die Wegfahrsperre oder die Synchronisierung des Kilometerstands zwischen KI und SAM, wo tatsächlich ein Dialog zwischen den Steuergeräten stattfindet, sind mit etwas Erfahrung dann ganz gut nachvollziehbar. 

 

bearbeitet vor 7 Stunden von 450-3

[450-3]

 

So sieht das dann übrigens in der Praxis aus. Frage war, ob man den eingeschalteten elektrischen Zuheizer im 450er CDI sehen kann.

 

 

Während der Zuheizer aktiv war, hat sich ein Status-Bit im zweiten Byte geändert. Die Nachricht 0x220 kommt vom SAM, das den Schalter auswertet.

 

bearbeitet vor 3 Stunden von 450-3

[MBNalbach]

Kann man damit soweit kommen das man einen smart, ohne Motor und physisches Meg einen sauber Laufenden Motor zu geben um zB ESP/Airbag/KI happy zu halten zb für nen e Umbau?

 

Hab sowas mal überflogen in Bezug auf eine Audi A2. Fährt mit allen Audi Systemen außer Motor. Dzm zeigt Akku stand an usw...

[450-3]

Für den 450 kann ich sagen, dass sich das KI auf jeden Fall ruhig stellen lässt, wenn die Nachrichten vom MEG simuliert werden. Sonst gehen ein paar der Warnlampen an und der berüchtigte eine Balken kommt in der Ganganzeige. Werte für Temperatur, Tank und die Ganganzeige kann man problemlos selbst setzen und auch die Warnlampen für eigene Zwecke steuern.

 

Dem SAM ist es relativ egal, ob ein echtes MEG vorhanden ist, es wird aber sicher ein paar Meldungen im Fehlerspeicher geben, wenn z.B. der Dialog für die Wegfahrsperre nicht nachgebaut wird. Die ZV und das anlernen der Schlüssel geht aber alles auch ohne MEG.

Wenn kein Motor mehr drin ist, hätte man sogar ein paar über CAN steuerbare Ausgänge frei, die für andere Zwecke verwendet werden könnten.

 

Das ESP dürfte vermutlich am ehesten Probleme machen, da es für den Regeleingriff auch eine Kommunikation mit dem Motorsteuergerät gibt. Müsste man sich auf jeden Fall sehr genau anschauen, damit man das dann auch in die eigene Steuerung nach dem Umbau integrieren kann.

Bei Bosch braucht man vermutlich nicht nach Unterlagen zu fragen 

 

bearbeitet vor 2 Stunden von 450-3

[MBNalbach]

Würde vermutlich eine halbe Lebensaufgabe werden... Beim 450 könnte man vermutlich am ehesten die komplette Technik eines ed3 umbauen in halber Zeit.