CAN-Hacking (war: OBD2 - ELM327 - Linux)

[Tachyon12]

Hallo Software-Gurus,

basierend auf den Ideen von "RScott" aus dem GM-Volt-Forum

http://gm-volt.com/forum/showthread.php?14144-Program-to-record-data-from-a-cheap-OBD2-scanner&highlight=obd2

RScott's Info:

http://www.evtools.info/ChevyVoltOBD2CAN.html

bin ich dabei einen OBD2-Scanner basierend auf dem HW-Interface ELM327 für den Apmpera/Volt unter Linux zu schreiben.

Folgender Status:

• Ineraktives Commando-Tool (CLI) für ELM327: funktioniert unter Python [ich liebe Python, weil leicht zu modifizieren, ...].
• Für die Bus-Geschwindigkeit von 500 kbps scheint aber der Python-Interpreter zu langsam zu sein [serial-Library].
• Deshalb wird optional von Python aus ein (auch standalone) C-Program aufgerufen [ich liebe C nicht, weil ...] [ftdi-Library].
• Output ist ein LogFile angelehnt an das Format von RScott.
• Das Ziel soll sein, die Liste der 11 bekannten CAN IDs (Stand 2012-10-24) des Primary Powertrain Bus zu erweitern.

Hat jemand Lust dabei mitzumachen und

• die Programme zu testen / zu erweitern
• Erfahrungen zurückzugeben
• zu riskieren, dass sein Ampera/Opel (Auto mit OBD) den Geist aufgibt
• natürlich auf jede Haftungs- / GarantieAnsprüche zu verzichten
• den C-Code zu verbessern

Ergänzung:
Ein DashDAQ besitze ich auch - nur ist es mir zu unflexibel...

Bei der eigenen Software, kann ich mir als ein Szenario vorstellen, dass die Daten über einen (Linux-)PC-in Echtzeit empfangen und über WLAN / WAN etc. weitergegeben werden, ...

Tachyon12

[gecko]

Hallo Tachyon,

Super was du da vor hast....endlich ein Mitstreiter. In einem anderen Tread habe ich ja mal geschrieben das OBD jeder kann und keine Kunst ist ...was zu beweisen ist :-)
Ich bin auch grad dabei den ELM auf meinen Ampera zu trimmen. Z.Z. bin ich noch in der Studium & Test Phase. Ich habe ja auch nicht den ganzen Tag Zeit dafür.
Was du vorhast ist ein passives Lauschen am CAN Bus und einfach alles mitzuschneiden was sich die Steuergeräte so zu sagen haben ... mit 500kbit. Ne Menge Daten, die man dann auch nicht braucht. Das ist auch nicht schwer mit dem Elm zu machen:
AT BRD 8 - 500kbit
AT H1 - headers on
AT MA - Monitor all
Das Erraten, was die Steuergeräte so den ganzen Tag beschäftigt ist viel schwerer. Also die Bedeutung aller Messages rauszubekommen.

Ich gehe aber einen etwas anderen Ansatz. Ich möchte dann doch lieber den DashDAQ Ansatz wählen, aber mit einem billig ELM. So schwer ist das auch nicht. Im OBD Standard mode 01h stehen nur normale abgasrelevante Messwerte (PID) zur Verfügung. Die stehen alle im OBD Standard drin.
Was wir brauchen sind die Hersteller PID's (sprich GM Volt Pids). Diese sind aber 2 Byte anstatt 1 Byte lang. DashDAQ macht das auch so und es gibt schon PID Listen hier im Forum. Lt. SAE J2190 kann man die PIDS mit Mode 22h abfragen. Mit Mode 24h kann man sogar Scaling & Offset der Messwerte PID‘s abfragen…cool. Dazu muss man aber den Elm entsprechen programieren. Zuerst muss man mit Funktionalen Adresse 7DFh alle Steuergeräte physikalische ID's rausbekommen. Dann kann man das Steuergerät, welches uns interessiert, mit der physikalischen Adresse und mode 22h ansprechen.
z.B.
Set functional addressing Header (always 7DFh, to which any module listening respond)
AT SH 00 07 DF
Set physical addressing Header (uses particular can ID, e.g. 720h for ford instrument)
AT SH 007 20
read propriatary data 22h from PID 116Bh
22 11 6B
SAE J 2178 gibt uns auch noch Auskunft, was sich hinter der phys. Adresse versteckt. Man kann den ECU namen auch mit mode 9 pid 0A abfragen. Für den Elm also 09 0A. Beim Ampera also sowas:
07E9 HybridPtCtrl HPC1
07EB FuelPumpCtrl FPCM
07EF B+EnergyCtrl BECM

Hier ist mal ein Link zum lesen.
http://obdcon.sourceforge.net/2010/06/obd-ii-pids/

und hier etwas schwerer:
http://www.canbushack.com/blog/index.php?title=scanning-for-diagnostic-data&more=1&c=1&tb=1&pb=1

Was die eigentliche Programmierung angeht bin ich kein Freund von Python....um Daten auszuwerten bzw. mal schnell was zu automatisieren ist das super.
Ich habe da eher an C# oder C++ gedacht. Bei MS gibs ja die Free Edition. Oder doch vielleicht Java. Da habe ich aber nciht viel Erfahrung.
Noch geiler wäre Labview. Da hat man auch gleich die entsprechnde Super Grafik dazu...aber Labview ist teuer. Meine Firma hat eine Lizenz.

LG

Geko

[gecko]

Ich nochmal, Hier ist ein besserer Link zum Canbushack. Der obige Link ist zu gefährlich. Irgendeinwelche Services aufrufen ohne zu wissen was man macht, kann dann schon mal irgendwas im FZ verstellen. Z.B. Anlernen der Lenkwinkelsensors...und schwubs kann ich nicht mehr lenken!

Deshalb nur das hier nehmen:
http://www.canbushack.com/blog/index.php?title=common-diagnostic-services&more=1&c=1&tb=1&pb=1

http://www.canbushack.com/blog/index.php?title=service-s-please&more=1&c=1&tb=1&pb=1

LG

Heiko

[Tachyon12]

Hallo Heiko,

danke für die Infos.
Werde sie durcharbeiten. Ich seh' schon, die Infos bringen mich weiter. Ich hab' auch nicht den ganzen Tag Zeit.

Zur Zeit bin ich offen für beide Ansätze:

• mit "Monitor all" den CAN-Bus scannen und die Daten später auswerten
• dezidierte PIDs senden (dazu muss man aber die richtigen PIDs kennen)

Ein Basis-Problem habe ich noch: Ich würde gerne den Laptop am ELM-hängend im Auto lassen und zum Beispiel das Laden der Batterie etc. loggen. Aber - wie auch schon in diesem Forum angefragt http://opel-ampera-forum.de/viewtopic.php?f=35&t=344&start=50 - bis jetzt kenne ich noch keine Möglichkeit, den CAN-Bus bei ausgeschaltener "POWER" aktiv zu halten.

Tachyon12

[gecko]

Hallo Tachyon,

Wir sollten mal das probieren:

Tester Present:
Definitely the most common service you’ll find, tester present (typically 0x3E) is used to let the controller(s) know that there is a.. wait for it.. Tester present. I know it was a bit obvious, but the idea is that some services keep the controller in an augmented state or a diagnostic state. When this happens there needs to be some way of maintaining that state while the tool that initiated the state is still connected to the diagnostic connector.
So Tester Present is designed to be a heart beet of the diagnostic tool and in the event that the device stops working or is disconnected from the network, the ECU whose state has been altered will stop seeing the tester present message and thus transition out of its altered state.
So if you want to maintain a diagnostic state you should send the tester present message. A typical timeout for Tester Present is 3 Seconds. So as long as you send the message between 1 and 2.5 seconds, you will be able to maintain the diagnostic state of a controller.

Das ist vom Link, den ich oben schon mal gesendet hatte http://www.canbushack.com/blog/index.php?title=common-diagnostic-services&more=1&c=1&tb=1&pb=1. Vielleicht verhidert der Mode (Service 3Eh), dass sich der Diagnose Gateway schlafen legt.
BTW: Du weisst aber schon, dass alles was über die OBD Buchse geht am Diagnose Gateway hängt? Der Gateway lässt nur das zu uns durch, was die Programmierer erlaubt haben. Wenn das Auto aus ist, wird der Gateway offensichtlich wg. Stromsparen abgeschalten.
Meine Hoffunung: Wenn man die Tester Present MEssage alle 2-3s sendet bleibt der Gateway ein.

LG

Heiko

[Chris]

Wenn das Auto aus ist, wird der Gateway offensichtlich wg. Stromsparen abgeschalten.
Meine Hoffunung: Wenn man die Tester Present MEssage alle 2-3s sendet bleibt der Gateway ein.

Ich denke, dass die Steuergeräte vom 12V Akku versorgt werden. Wenn die Steuergeräte nun nicht abschalten wird das den Stromverbrauch in die Höhe treiben und auf kurz oder lang den 12V Akku entladen....

Gruß Chris

Gesendet von meinem Samsung Galaxy Ace mit Tapatalk

[gecko]

Îch habe nochmal studiert :-) Der Diagnose Gateway leitet eigentlich nur die CAN Messages weiter und interpretiert nichts, wenn es nicht an ihn gerichtet ist. Die Tester present message ist ja eigentlich nicht an den Gateway gerichtet sondern an irgendein Steuergerät mit dem man gerade kommuiziert. Jetzt kommt es natürlich darauf an, welche Prio die Diagnose im Fahrzeugnetzwerk hat. Es kann schon sein, dass die Systeme bzw. Programmierer entschieden haben dass die diagnose nicht wichtig ist und beim Ausschalten der Zündung wird der Gateway schlafen gelegt.

Aber probieren geht über studieren!

Ich denke, dass die Steuergeräte vom 12V Akku versorgt werden. Wenn die Steuergeräte nun nicht abschalten wird das den Stromverbrauch in die Höhe treiben und auf kurz oder lang den 12V Akku entladen....

Ich glaube nicht das Tachyon tage- bzw. wochenlang das laden der Batterie beobachten will.

LG

[Tachyon12]

Ich denke, dass die Steuergeräte vom 12V Akku versorgt werden. Wenn die Steuergeräte nun nicht abschalten wird das den Stromverbrauch in die Höhe treiben und auf kurz oder lang den 12V Akku entladen....

Ich glaube nicht das Tachyon tage- bzw. wochenlang das laden der Batterie beobachten will.

LG

...ausserdem wird die 12-Volt Batterie auch geladen, wenn das Auto an 220 V hängt...

Tachyon12

[Chris]

...ausserdem wird die 12-Volt Batterie auch geladen, wenn das Auto an 220 V hängt...

Tachyon12

Ok. Dann war mein Kommentar wohl überflüssig.
Ich meine nur mal irgendwo im Forum gelesen zu haben. Dass der 12V Akku nur geladen wird wenn das Fahrzeug eingeschaltet ist. Und normal ist gilt es beim Laden als ausgeschaltet.

Gruß Chris
Gesendet von meinem Samsung Galaxy Ace mit Tapatalk

[Tachyon12]

@Chris
Dein Kommentar war NICHT überflüssig, weil es wirklich nicht auf Anhieb klar ist, WANN die 12-V Batterie geladen wird.

@gecko
In welche Kommando-Sequenz ist die "Tester Present"-Message einzubinden?
Danke.

Arbeitest Du (nur) mit Windows?

Tachyon12

------
Von meinem uuuuralten iPad mit Safari im Ampera sitzend (am LadeKabel hängend) geschrieben ;-)