Schliesst man ein Oszi an die K-Line an, ergibt sich folgendes Bild, sofern man ueber den ELM eine PID von der ECU anfordert:
IMG_20190730_100125.jpg
Die 7 linken senkrechten Striche sind die Anfragen des ELM an die ECU (7 Byte mit Pausen zwischen die Bytes), der breitere Strich links der Mitte ist die Antwort der ECU (8 bzw. 9 Byte fast ohne Pausen). Nach einer Pause von ca. 120ms wiederholt sich das Ganze. Im Prinzip handelt es sich um eine serielle Schnittstelle, aehnlich der RS232. Allerdings sind die Pegel 12V und 0V, wobei 12V einer logischen 1 entspricht, und 0V entsprechend logisch 0. Die Geschwindigkeit der Schnittsytelle betraegt ungewoehnliche 10400 Baud. Das Uebertragungsformat ist 8N1, dh. nach einem Startbit (log 0) folgt ein Byte (8 Bit), und als Abschluss wieder ein Stoppbit (log 1). Auf ein Paritaetsbit wird verzichtet. Idle (Stille) ist hier ebenfalls log 1. Beim Byte wird das niederwertigste Bit zuerst uebertragen (LSB first)
IMG_20190730_100246.jpg
Eine typische Antwort der ECU ist im Oszillogramm zu sehen. Die Kaestchenbreite betraegt 1ms, dh in ein Kaestchen passen etwa 10 Bit (bei 10400 Baud). nach dem Startbit ganz links (erster 1-0 Uebergang ) folgt 00100001 nach einer Pause von etwa 0,2ms kommt das naechste Startbit und die Folge 10101111 usw. Hexadezimal wird also zuerst eine 0x84 und dann eine 0xF5 gesendet (Achtung LSB first: dh Bitstrom rueckwaerts interpretieren).
Fuer mein Projekt (Spritverbrauchsmesser) brauche ich folgende Sensoren, und auf die beschraenke ich mich erstmal auch:
- FUELPW1: Oeffnungszeit der Einspritzduesen
- RPM: (selbsterklaerend)
- VSS: Geschwindigkeit
Fordert man diese Sensorwerte an, kann man auf der K-Line folgende Byte an die MCU mitlesen:
FUELPW1 |
0x64,0x10,0xF5,0x22,0x17,0x62,0x04 |
RPM |
0x64,0x10,0xF5,0x22,0x17,0x38,0xDA |
VSS |
0x64,0x10,0xF5,0x22,0x17,0x4A,0xEC |
Ab hier wird jetzt tlws. Raterei, weil das Protokoll nirgends beschrieben wird. Falls jemand das Ford Protokoll kennt, bin ich fuer Erhellung dankbar....
Man erkennt , dass die ersten 5 Byte immer dieselben sind. Wahrscheinlich bedeutet 0x64 "Anfrage einer PID". 0x10 und 0xF5 sind moeglicherweise Sende und Empfangsadressen der beiden Kommunikationspartner ELM und ECU, da diese sich bei den Anworten der ECU getauscht gesendet werden (s.u.). Fuer 0x22 und 0x17 habe ich leider keine Erklaerung.
Das sechste Byte beschreibt jeweils die PID, dh 0x62 ist die Einspritzzeit, 0x38 die Umdrehungen und 0x4A die Geschwindigkeit. Das letzte Byte ist ein Checksummen Byte. Es berechnet sich einfach aus der Summe der bereits gesendeten 6 Byte, abgeschnitten auf 8 Bit (modulo 0xFF):
0x64+0x10+0xF5+0x22+0x17+0x4A = 0x1EC ( modulo 0xFF: 0xEC)
Die Antworten der ECU sehen jeweils exemplarisch so aus:
FUELPW1 |
0x84,0xF5,0x10,0x62,0x17,0x62,0x04,0x90,0xF8 |
RPM |
0x84,0xF5,0x10,0x62,0x17,0x38,0x0D,0xAC,0xF3 |
VSS |
0x74,0xF5,0x10,0x62,0x17,0x4a,0x26,0x62 |
Man sieht, dass die ECU unterschiedlich lange Antworten zurueckliefert. Die reinen Sensorwerte sind dabei 1 oder 2 Byte lang. Das erste Byte immer entweder 0x74 oder 0x84. Dann folgen wieder die Adressen 0xF5 und 0x10. Es folgt eine 0x62, 0x17 und schliesslich wieder die angeforderte PID Adresse (0x62 , 0x38 oder 0x4A). Danach folgen die Sensorwerte.
Ist das erste Byte 0x74, ist der Sensorwert 1 Byte lang, waehrend er bei 0x84 2 Byte lang ist. Abschliessend folgt wieder eine Checksumme, die wie oben berechnet wird.
Interpretation der Werte:
Die uebermittelten Sensorwerte muessen in physikalische Groessen umgerechnet werden. Dabei sind 2 Byte als 16-Bit Zahlen zu interpretieren die wie folgt berechnet werden: 7te Byte * 256 + 8te Byte.
Als Ergebniss erhalten wir in unserem Beispiel also als Dezimalwerte:
FUELPW1 |
1164 |
RPM |
3500 |
VSS |
38 |
Fuer die Einspitzzeit muss der Wert durch 512 geteilt werden, der Zahlenwert ist als ms zu interpretieren. In diesem Beispiel bedeutet es eine Einspritzzeit von 2,27 ms. Die Umdrehung kann direkt als Umdrehung pro Minute interpretiert werden, also hier 3500 upm. Fuer die Geschwindigkeit wird der Zahlenwert verdoppelt, also hier 76 km/h.
Beitrag automatisch zusammengeführt
Zitat von
da_user
Den entsprechenden Artikel von Forscan habe ich hier schonmal in einem ELM327-Thread verlinkt:
https://forscan.org/forum/viewtopic.php?f=4&t=5
Als Software würde ich hier übrigens eher das vollwertige ForScan für Windows empfehlen. Braucht halt einen Laptop od. ähnl. mit Windows. Ist dafür allerdings bei praktisch vollem Funktionsumfang kostenlos.
M.W. hat ja der NA("FL") auch eine solche Diagnosebuchse. Interessant wäre, ob da auch dieser Bus anliegt und man diesen auslesen kann.
Ich vermute nein:
Erstens war zur NA-Zeit noch kein OBD in den USA vorgeschrieben, und zweitens blinkt der NA zweistellige Fehler, waehrend der NB 4-stellige OBD2 Errors ausblinkt.
Aber das sagt mir nur die Kristallkugel. Leider habe ich keinen NA, das muss ein Dritter testen