ODB 244er / was spricht der 244er

Moin,

ich hab grad das leidige Thema wegfahrsperre beim 244er. Da ich das Auto per AlfaODB-App und Notfallcode starten kann (was der TÜV mir aber nicht durchgehen lässt) versuche ich grad eine Lösung per Microcontroller.

Grundannahme ist folgende: Mit so einem billigen 30€ ODB Stecker und der AlfaODB-App kann ich das Auto im Notfallmodus mit meinem Notfallcode freischalten. Hier redet also die App per Bluetooth mit dem ODB-Stecker und der irgendwie mit dem Auto. Ich war naiv genug anzunehmen das es sich hierbei um CAN handelt.

Ich habe mir also ein Zwischenstück zwischen ODB Bluetooth-Adapter und Schnittstelle am Auto gemacht und versucht mitzulesen was AlfaODB mit dem Auto redet wenn der Notfallcode eingegeben wird.
Anschließend wollte ich das ganze dann automatisiert per Microcontroller statt Bluetooth und App machen (damit es schneller geht als mit der App)

Leider scheint das Auto kein CAN zu sprechen und selbst mit dem Oszilloskop war ich nicht in der Lage irgendwo Kommunikation zu erkennen, obwohl das Auto grade mit dem ODB verbunden war und die Freischaltung gemacht hat.

Hat jemand Ahnung auf welchen Pins der Ducato mit diesem Dongle spricht, welches Protokoll, welche Baudrate?
Wie muss ich das mit dem Oszi messen? (da es offensichtlich Kommunikation gibt bin wohl nur zu blöd sie zu messen)

Ich bin für jede Info dankbar
Jay

Bin begeistert!

Anbei ein Screenshot der oben verlinkten Supported Vehicles. Es ist tatsächlich das Bosch EDC15 CF3 mit dem sich bei mir AlfaODB verbindet um den Code einzugeben.

Jetzt muss ich mir die geballte Info erstmal zu Gemüte führen und schauen ob ich es verstehe ...

So, ich bin der Thematik ein Schritt weiter auf die Pelle gerückt (und gleichzeitig ist das Thema für mich in der Praxis erstmal gelöst):

Gelöst weil ich mir bei Ebay ein Steuergerät gekauft habe bei dem die Immo ausprogrammiert wurde. Habs getauscht, der Wagen springt jetzt an. Feddich.

Dem Bastler in mir lässt aber die andere potentielle Lösung keine Ruhe und so hab ich beschlossen das weiter zu verfolgen wenn die Zeit es zulässt. Was ist bisher gelaufen:

1. Bisher hab ich immer mit AlfaODB per HandyApp und einem Bluetooth Adapter gearbeitet. Das hat stellenweise 2 Minuten gedauert bis die Verbindung stand und ich per Notstartcode das Auto starten konnte.
Jetzt habe ich mir zunächst mal einen billigen 20€ ELM327 Nachbau mit USB-Anschluss besorgt und AlfaODB auf den Laptop installiert. Damit geht die Verbindung zum Auto deutlich schneller. (Meine Vermutung das die meiste Zeit dabei draufgeht das Handy und Bluetooth-ELM sich finden sehe ich damit bestätigt)

2. Ich habe mir eine Testversion eines Com-Monitors installiert. Hintergrund: Der USB-ELM wird als Serielle Schnittstelle, sprich COM-Port, unter Windows eingebunden. Das kann man im Gerätemanager und COM-Port schön sehen wenn man den USB-Stecker einstöpselt. Im Com-Monitor kann man jetzt den Datenverkehr zwischen AlfaODB und dem ELM mitschneiden.

3. Mitschnitt starten und das Auto per Notstartcode aus AlfODB starten.

4. Mitschnitt analysieren....
In diesem Schritt bin ich jetzt. Wenn ich die im Netz zu findenden ELM AT-Command Listen anschaue erkenne ich was in etwa da passiert. Manche Werte die als HEX-Werte geschickt werden bleiben mir bisher unklar. Die Zeile in der der Notstartcode geschickt wird konnte ich allerdings bereits ausmachen.

5. Jetzt wäre es an der Zeit fogende Schritte durchzuführen:
1. Einen weiteren ODB-Adapter nehmen und sich mit einem geeigneten Mikrocontroller an die Rx und Tx Pins des ELM327 (oder entsprechenden Clone, vermutlich ein PIC18f25k80) zu hängen. Ich würde dafür vermutlich einen Arduino nehmen. Unbedingt auf die Spannungspegel achten. Arduino hat of 5V, ich vermute die ELMs eher 3,3V. Ggf. muss man da einen Pegelwandler zwischenschalten.
Wenn man nun in der Lage ist vom Arduino aus AT-Kommandos zu schicken und Antworten auzuwerten...

2. Den aufgezeichneten Datenverkehr per Arduino loszuschicken sobald der Zündschlüssel gedreht wird und das Steuergerät bereit ist mit dem Gebastel zu reden.

Könnte so klappen, ich hoffe das ich dazu komme diesen Gedanken weiter zu verfolgen. Jetzt ist allerdings erstmal dran ein paar Löcher durch Rep-Bleche zu ersetzen und durch den TÜV zu kommen.

Zitat von targa

Wenn es 3.3V UART Signale sind, nimm doch einen ESP8266, der läuft komplett auf 3.3V und ist voll mit der Arduino IDE kompatibel, viel kleiner und auch noch wesentlich billiger.

Jepp, das ist ne gute Idee.

Zitat von targa

Man könnte aber auch hergeben und sich direkt auf die K/L Protokollebene begeben und ohne ELM327 arbeiten, wenn man eh schon dabei ist, Datenströme zu analysieren. Und vorher mal googlen, ob das nicht schon jemand gemacht hat.

Da hab ich tatsächlich schon etwas Energie reingesteckt und diesen Pfad sofort verlassen als ich ne einfachere Lösung vor Augen hatte (und grandios daran gescheitert bin die Kommunikation mit dem Oszilloskop zu messen).
Das schöne an der Lösung mit ELM327 und deren Derivaten ist das sie mit ner fertigen Beschaltung usw herkommen und mir so ne Menge elektrotechnisches Geschwurpsel abnehmen. Außerdem hab ich wenig Ambitionen jetzt auf unterster Schicht der Protokolle Reverse Engineering zu betreiben. Ich hab eh schon Schwierigkeiten vernünftige Info und Doku zu bekommen.

Das ganze mache ich ja nicht aus bloßem Selbstzweck und Spaß an der Freude, sondern ursprünglich wollte ich einfach nur dafür Sorgen das mein Auto durch den TÜV kommt. Wenn ich das Thema jetzt weiter verfolgen sollte, dann nur um ggf. anderen, die nicht das Glück haben ein umprogrammiertes Steuergerät zu finden, ein weitere Möglichkeit zu geben.

Solltest Du auf der K/L Protokollebene Doku oder Erfahrung haben und derartiges in Angriff nehmen wollen werde ich aber bestimmt mitdenken..