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

[gecko]

ich habe noch ein bisschen gesurft. Schau mal auf http://www.obdtester.com und lade das gm-tool mode 22 von terry. Das scheint genau zu sein was wir brauchen. Kann erst heute abend wieder testen. Lg heiko

[Tachyon12]

Aber wie ist jetzt die Zuordnung von den DashDAQ "PID"s - die sind ja 4-stellig, dezimal (?) - zu CAN-Cmds?

Hallo Tachyon,

ich habe es noch nicht probiert...aber lt. Theorie musst du folgendes machen:

a) Wir lassen jetzt erstmal alles auf Default beim ELM und Initialieren den ELM mit
ATZ 'Reset
ATRV 'read Voltage
ATSP0 'set Auto Protocol
0902 'read VIN
ATDP 'show protocol
ATH1 'show headers

jetzt lass uns einfach mal Service 22h mit PID 0000 in die runde senden und schauen ob wer antwortet:
22 00 00
wenn keiner antwortet, dann vielleichtmal PID 06 3E (Dashdaq: 1598 "ECT" "Engine Coolant Temperature""°C" 0), also:
22 06 3E

Wenn das alles noch nichts hilft, müssen wir wohl mal eine ECU direkt ansprechen. Also:
AT SH 7E8 'das ist die ECM EngineControl ECU
22 06 3E

Wenn das jetzt immer noch nicht geht, dann müssen wir noch tiefer in die Trickkiste greifen ...aber das muss ich mir dann nochmal genauer anschauen....

LG

Heiko

Hallo Heiko,

das Ergebnis:

Code: Alles auswählen

# DATE=20121026 17:39:40.322
# SOFTWARE=./pyAmperaCLI.py 1.7 2012/10/26 14:00:00
17:41:39.412: Cmd: at rv
17:41:40.426: 12.8V
17:41:40.426:

17:41:45.307: Cmd: atz
17:41:47.106:
17:41:47.106:
17:41:47.106: ELM327 v1.4b
17:41:50.539: Cmd: at rv
17:41:51.553: at rv
17:41:51.553: 12.7V
17:41:55.988: Cmd: at e0
17:41:56.997: at e0
17:41:56.997: OK
17:42:03.476: Cmd: at sp 0
17:42:04.485: OK
17:42:08.588: Cmd: at dp
17:42:09.597: AUTO
17:42:15.347: Cmd: 0902
17:42:16.817: SEARCHING...
17:42:16.817: 014
17:42:16.817: 0: 49 02 01 31 47 30
17:42:16.817: 1: 52 38 36 45 34 33 43
17:42:16.817: 2: 55 31 31 33 34 37 39
17:42:25.068: Cmd: at dp
17:42:26.085: AUTO, ISO 15765-4 (CAN 11/500)
17:42:31.234: Cmd: at h1
17:42:32.242: OK
17:42:43.261: Cmd: 22 00 00
17:42:43.303: 7EB 07 62 00 00 80 40 00 01
17:42:43.303: 7E8 07 62 00 00 BE 7F B8 13
17:42:43.303: 7EA 07 62 00 00 80 00 00 01
17:42:43.303: 7EF 07 62 00 00 00 00 00 01
17:42:43.303: 7E9 07 62
17:43:14.090: Cmd: 22 06 3e
17:43:15.304: NO DATA
17:43:57.037: Cmd: at sh 7e8
17:43:58.046: OK
17:44:08.704: Cmd: 22 06 3e
17:44:09.916: NO DATA
17:44:25.859: Cmd: q

Tachyon12

[Tachyon12]

Hallo Heiko,

ich habe mir noch 'mal die ELM327-Dokumentation angesehen.

Auf Seite 39:
The 7E8 shows that ECU#1 was the one responding. In order to talk directly to that ECU, all you need do is to set the header to the appropriate value (it is 7E0 to talk to the 7E8 device – see ISO 15765-4 for more information). From that point on, you can ‘talk’ directly to the ECU using its physical address, as shown here:

Code: Alles auswählen

# DATE=20121026 19:04:10.953
# SOFTWARE=./pyAmperaCLI.py 1.8 2012/10/26 16:00:00
19:04:15.605: Cmd: atz
19:04:17.404: 
19:04:17.404: 
19:04:17.404: ELM327 v1.4b
19:04:22.736: Cmd: at rv
19:04:23.750: at rv
19:04:23.750: 14.7V
19:04:27.415: Cmd: at e0
19:04:28.424: at e0
19:04:28.424: OK
19:04:34.848: Cmd: at sp 0
19:04:35.856: OK
19:04:41.557: Cmd: 09 02
19:04:43.034: SEARCHING...
19:04:43.034: 014 
19:04:43.034: 0: 49 02 01 31 47 30 
19:04:43.034: 1: 52 38 36 45 34 33 43 
19:04:43.034: 2: 55 31 31 33 34 37 39 
19:04:47.608: Cmd: at dp
19:04:48.626: AUTO, ISO 15765-4 (CAN 11/500)
19:04:51.371: Cmd: at h1
19:04:52.380: OK
19:04:57.788: Cmd: 22 00 00
19:04:57.832: 7E8 07 62 00 00 BE 7F B8 13 
19:04:57.832: 7EF 07 62 00 00 00 00 00 01 
19:04:57.832: 7E9 07 62 00 00 80 00 00 01 
19:04:57.832: 7EA 07 62 00 00 80 00 00 01 
19:04:57.832: 7EB 07 62
19:05:10.088: Cmd: 22 06 3e
19:05:11.303: NO DATA
19:05:23.396: Cmd: at sh 7e0
19:05:24.405: OK
19:05:33.233: Cmd: 22 06 3e
19:05:34.305: 7E8 03 7F 22 31 
19:06:16.981: Cmd: q

"22 06 3e" liefert also " 7E8 03 7F 22 31".

Wenn 31h die Temperatur ist, dann ist das 49 ... 40 Offset abziehen -> 9°C ?

Wert ist plausibel, weil das die momentane AussenTemperatur ist.

HTH

Tachyon12

[gecko]

Hallo Tachyon!

(it is 7E0 to talk to the 7E8 device – see ISO 15765-4 for more information)

Ja du hast recht! Das habe ich übersehen! COOL! Damit haben wir es!!!!
Jetzt können wir alles was DashDAQ kann!!!! und noch viel besser!

PS: Ich schau mir jetzt nochmal " gm-tool mode 22 von terry" an. Vielleicht gibs noch ein paar Geheimnisse, die ich übersehen habe :-)

LG

[gecko]

Hallo Tachyon,

du wirst es schon gemerkt haben :-( Es kommt bei jeder PID immer nur 7E8 03 7F 22 31 zurück. Das wars wohl nicht...also weiter studieren :-(

LG

[Tachyon12]

Hallo Tachyon,

du wirst es schon gemerkt haben :-( Es kommt bei jeder PID immer nur 7E8 03 7F 22 31 zurück. Das wars wohl nicht...also weiter studieren :-(

LG

Hallo gecko,

das Ergebnis "7E8 03 7F 22 31" ist ja auch ein "gutes" Ergebnis, weil es ein "richtiges" ist.
Auf Seite http://obdcon.sourceforge.net/2010/06/obd-ii-pids/ steht ganz unten unter "Response":

"...general request usually indicating that the module doesn't recognize the request."

Tachyon12

[Hybrid_man]

Hallo zusammen,

mitreden oder gar helfen kann ich da leider nicht, möchte euch aber ermutigen - wenn das dazu führt, daß man mit einem normalen Scangauge II (hatte das in meinem Prius III) oder sonstwas relevante Daten mitlesen kann, ist das eine klasse Arbeit ! (auch um anderen die Funktionen und Arbeitsweise des Autos zu erklären am lebenden Objekt)

viele Grüsse
Hybrid_man

[Tachyon12]

@Hybrid_man
danke für den Zuspruch :-)

@gecko et al.
Ich hänge jetzt am Problem:

Aber wie ist jetzt die Zuordnung von den DashDAQ "PID"s - die sind ja 4-stellig, dezimal (?) - zu CAN-Cmds?

Dazu habe ich bisher folgende Infos:

• http://www.youtube.com/watch?v=q60ORePwJ9g
  Video (vermutlich) von einem Slowenen, der die Android App "Torque" verwendet.
  In den Kommentaren steht, das für SOC PID 01 5B verwendet wurde und der Autor die PIDs von einem Chevy Volt Besitzer hat.
• Im ensrpechenden Forum http://torque-bhp.com/forums/?wpforumac ... c&t=1253.1 wird über Some Extended GM PIDS found online diskutiert, aber die Links führen bei mir immer zu 404 :-(
• Ich habe mir ein kleines Script geschrieben, welches zu den DashDAQ Available Signals das "Signal" in Hex davorstellt ;-)

  Code: Alles auswählen

   60E		1550	"HV SOC Gauge"	"High Voltage Battery State of Charge Gauge Position"	"%"	1
   676		1654	"HV SOC"	"Hybrid Battery Pack Remaining Charge"	"%"	1
   627		1575	"HV SOC"	"Hybrid Battery State of Charge (HCP)"	"%"	1
  

  aber da komme ich nie auf PID 01 5B.
  In der deutschen DashDAQ-Anleitung wird immer von Signalen gesprochen - PID kommt nicht vor ...
• Auf RScott's EV Tools-Seite http://www.evtools.info/ChevyVoltOBD2CAN.html hat SOC Battery die PID 206 (mit der "Monitor All"-Methode erstellt).

Weiss jemand mehr?

Tachyon12

[gecko]

Hallo Tachyon,

Lass dich nicht auf die falsche Fährte führen!!

In den Kommentaren steht, das für SOC PID 01 5B verwendet wurde und der Autor die PIDs von einem Chevy Volt Besitzer hat.

PID 01 5B ist mode 01 mit PID 5B. Du brauchst da dem ELM nur 015B senden. Hier sind die normalen PID erklärt.
http://en.wikipedia.org/wiki/OBD-II_PID ... coded_PIDs Da findest du auch 5B "Hybrid battery pack remaining life". Das können wir schon!

...Some Extended GM PIDS found online diskutiert, aber die Links führen bei mir immer zu 404 :-(

Also soweit ich verstanden habe gibt es generelle GM extended PIDs und dann gibs noch die speziellen VOLT PIDs.

Auf RScott's EV Tools-Seite http://www.evtools.info/ChevyVoltOBD2CAN.html hat SOC Battery die PID 206 (mit der "Monitor All"-Methode erstellt).

Ja, das habe ich aber oben schon erklärt. Das scheint keine PID zu sein sondern die CAN ID von irgendeiner ECU, die auf dem CAN Bus irgendwas irgendeiner anderen ECU erzählt. Rscott hat wohl rausbekommen, dass dies SOC ist.
Das bring uns aber nicht weiter....weil wir hier nicht aktiv nach Daten fragen können sondern immer warten müssen bis irgendeine ECU dies sendet. Und wenn man einen Bluetooth ELM hat, bekommt man beim passiven Lauschen und ohne Filter sowie nur "Buffer full".

Meine Annahme ist, dass die Signale von DashDAQ PID's sind, die man am CAN Bus abfragen kann. Ich kann natürlich auch falsch liegen. Dann haben wir aber ein Problem. Ohne org. GM Unterlagen kommen wir dann nicht weiter.
Gestern aben habe ich in VBS Script einen kleinen PID scanner gebastelt und habe mal geschaut wo positive antworten kommen. PID 0000 - 0060 kommen ne menge, was auch klar ist, da ja die normalen OBD Pids. Ab 0060 nur noch sporadisch. Ab 2000 sind dann wieder ein paar und ab D0000. Das passt natürlich jetzt nicht ins Bild mit DashDAQ, denn von 0100-0700 kommt nur Fehler.

Hmm, ich bin der Meinung, dass wir hier die ECU's falsch ansprechen bzw. mit der falschen Methode die PIDs lesen....muss aber noch weiter studieren, um alles zu verstehen.

Ich habe mir dann auch mal das GM scantool mode 22 angeschaut. Das Program sendet folgendes an die ECU...werd ich gleich nachher nochmal probieren:
ATZ
ATE1
ATSH 6C 10 F1
ATST 10
22 000C 01
22 000D 01
22 000F 01
22 0011 01
22 0004 01
22 0010 01
22 0005 01
22 0006 01
22 0007 01
22 11A1 01
22 000B 01
22 000E 01
22 0001 01
22 1141 01
22 0014 01
22 0018 01
22 0003 01
22 119B 01
22 1152 01
22 1171 01
22 0008 01
22 0009 01

Das Program benutzt also das VPW J1850 Protokoll und den entsprechenden Header, hier ist mehr davon zu finden und auch mögliche PID's :
http://www.fastfieros.com/tech/vpw_comm ... otocol.htm

[Tachyon12]

Halli gecko,

ist ja spannend.
Versuche grad AT SH 6C 10 F1 zu verstehen.
SH ... Set Header
6C ... Priority mit fixer Länge von 12 Bytes???
10 ... Receiver - an den gehts
F1 ... Transmitter - Konvention für Scanner-Gerät
Stimmt das so?
Quelle: ELM-Manual

Tachyon12