Kombiinstrument - Anpassen der Wegstreckenzahl

Aus T4Forums Doku
Zur Navigation springenZur Suche springen

Verbaut man eine andere Reifengröße als ab Werk vorgesehen war, so kann es sein, das man die Wegstreckenzahl (auch Wegimpulszahl oder K-Zahl genannt) anpassen muss.

grünes KI(1996 - 1998)

Die Wegstreckenziffer ist an den Stellen 0xDC und 0xDD abgelegt.

Für einen ACV mit 2WD-Schaltgetriebe lautet die Wegstreckenziffer 3407, was im Hexadezimalsystem 0x0D4F ergibt. Im Speicher des Kombiinstruments findet man den gedrehten Wert "4F 0D"

Beispiel: Ändern der Wegstreckenziffer

Im folgenden Beispiel soll das Kombiinstrument eines ACV-Fronttrieblers auf eine Bereifung der Größe 225/55/R17 angepasst werden. Deren Abrollumfang ist um 4,9% größer als die Standardbereifung 205/65/R15, was bedeutet, dass die Wegstreckenziffer um 4,9% kleiner werden muss.

Daraus ergibt sich eine neue Wegstreckenziffer von 3240, was umgerechnet ins Hexadezimalsystem 0x0CA8 ergibt. Nach dem drehen der Bytes ergibt sich ein Speicherinhalt von "A8 0C" der in den Speicher geschrieben werden muss


Blaue KIs

Die Berechnung der neuen Wegstreckenzahl geht genau wie bei den grünen KIs. Die Besonderheit bei den blauen KIs ist jedoch, das die Wegstreckenzahl mit einer Checksumme geschützt ist.

Der Speicherort der Wegstreckenzahl unterscheidet sich je nach KI-Generation. Einige (wenige) Offsets finden sich hier.

Meist ist die voreingestelle Wegstreckenzahl die "3407" (Codierung 2, 15" Fahrwerk ACV). 3407 wird in HEX als "0D 4F". Nach Byteflip wird "4F 0D" daraus. Diesen Wert kann man dann in seinem Dump suchen, um seine Speicherstelle zu ermitteln.

Ändert man diese Wegstreckenzahl nun einfach auf beispielsweise "3171", also in HEX und nach Byteflip "63 0C" und spielt dieses Dump zurück, dann zeigt das KI promt "dEF." anstelle des Tageskilometerzählers. Schuld ist die Checksumme, die noch berechnet werden muss.

Um die Checksumme zu berechnen, muss man die Formel ermitteln, aus der die Checksumme gebildet wird. Sofern die Formel noch nicht bekannt ist, muss sie (zeit-)aufwändig ermittelt werden.


Bekannte Checksummen-Formeln

!!! Funktioniert so nicht !!!

Bitte mit „Formel nicht bekannt“ fortfahren


  • 7D0 920 802 Q: f(x)= -1 * x + 3619
  • 7D0 920 803 B: f(x)= -2 * x + 6822
  • 7D0 920 821 D: f(x)= -2 * x + 7052
  • 7D0 920 822 J: f(x)= -1 * x + 3730
  • 7D0 920 841 B: f(x)= -2 * x + 7045
  • 7D0 920 842 H: f(x)= -1 * x + 3740

"x" steht für die neue Wegstreckenzahl, "f(x)" für die Checksumme.

Wichtig: die Checksumme darf nur zwischen 0 und 255 betragen. Ist sie größer, zieht man (ggf. mehrfach) 255 ab, bis man in dem Bereich landet. Ist sie kleiner addiert man (ggf. mehrfach) 255.

Die Checksumme wird danach wieder als HEX-Zahl umgerechnet.

Hinweis: Die Formeln sind nicht exakt. Es kann sein, das die richtige Checksumme um 1 größer oder kleiner als das berechnte Ergebnis ist.

Formel der Checksumme ist unbekannt

Als Vorarbeit muss das KI auf jede mögliche Reifengröße (1 - 8) codiert und ein Dump des KIs erstellt werden. Sodass man im Anschluss acht verschiedene Dumps hat.

Diese Dumps vergleicht man alle miteinander und schreibt heraus, welche Werte sich unterscheiden.

Exemplarisch zeige ich das an meinem KI:

7D0 920 803 B
Codierung 0x016C 0x011C 0x011D 0x0129 0x012A 0x012C 0x012D 0x012E 0x012F Wegstreckenzahl
01111 0x28 0x11 0x01 0x02 0x6F 0x1B 0x0D 0x1B 0x0D 3355
01112 0x26 0x22 0x02 0x02 0x07 0x4F 0x0D 0x4F 0x0D 3407
01113 0x28 0x33 0x03 0x03 0x1F 0xC3 0x0D 0xC3 0x0D 3523
01114 0x2A 0x44 0x04 0x03 0x93 0x89 0x0D 0x89 0x0D 3465
01115 0x2A 0x55 0x05 0x02 0xDF 0xE4 0x0C 0xE4 0x0C 3300
01116 0x2C 0x66 0x06 0x03 0xAD 0xFD 0x0C 0xFD 0x0C 3325
01117 0x2E 0x77 0x07 0x03 0x4D 0xAC 0x0D 0xAC 0x0D 3500
01118 0x2C 0x88 0x08 0x02 0xE9 0xDE 0x0D 0xDE 0x0D 3550

0x12E und 0x12F ist eine Wiederholung von 0x12C und 0x12D. Dort steht die eigentliche Wegstreckenzahl.

0x11C und 0x11D sind die letzte Ziffer der Codierung, im ersten Feld steht es doppelt (aus Codierung xxxx1 wird "11"), im zweiten mit führender Null.

Feld 0x016 habe ich erst für eine Art Checksumme der Codierung gehalten, aber es ist dem KI scheinbar egal, was dort steht. Ich habe dort die "26" gelassen.

Für Feld 0x129 habe ich auch keine Erklärung, da steht mal die "02" und mal die "03". Ich habe dort die "02" stehen gelassen.

Bleibt noch das Feld 0x12A übrig - das ist die Checksumme der Wegstreckenzahl.


Für die weitere Untersuchung bin ich ins Dezimalsystem gewechselt:

Codierung Checksumme Wegstreckenzahl
01111 111 3355
01112 7 3407
01113 31 3523
01114 147 3465
01115 223 3300
01116 173 3325
01117 77 3500
01118 233 3550

Das wirkt noch recht willkürlich, also habe ich nach der Größe der K-Zahl sortiert:

Wegstreckenzahl Checksumme
3300 223
3325 173
3355 111
3407 7
3465 147
3500 77
3523 31
3550 233

Das habe ich dann graphisch dargestellt. Auf der X-Achse befindet sich die Wegstreckenzahl, auf der Y-Achse die Checksumme:

K Zahl1.PNG

Es fällt auf, dass die Steigung der "fallenden" Linien doch sehr ähnlich aussieht. Also habe ich mich erstmal nur auf die ersten vier Datenpunkte beschränkt und mit Excel eine Trendlinie erzeugt:

K Zahl2.PNG

Die Formel der Trendlinie lautet: -2.0216 x + 6894.1. Mit dieser ersten Formel habe ich dann die anderen vier Werte neu berechnet und in das Diagramm eingefügt:

Trendlinie hier einfach ignorieren

Das in Tabellenform:

Wegstreckenzahl Checksumme (aus Dump) Checksumme (nach Formel) Differenz
3300 223 223 0
3325 173 173 0
3355 111 111 0
3407 7 7 0
3465 147 - 110.744 257.744
3500 77 - 181.5 258.5
3523 31 - 227.9968 258.9968
3550 233 - 282.58 515.58

Bei den ersten vier Wegstreckenzahlen sind die Checksummen identisch, was nicht verwundert, da ich anhand dessen ja die Formel errechnet habe. Die anderen vier sind errechnet, aber negativ und mit Nachkommastellen. Ein wenig auffällig finde ich die Differenz: das liegt doch erschreckend nah an 255 (und an 255 mal 2: 510).

Da ich mir nicht vorstellen kann, das die Formel intern so krumm ist (- 2.0216 x + 6894.1), habe ich sie mal gerundet auf: - 2 x + 6822. Damit habe ich die Checksummen nochmal nachgerechnet:

(Auf negative Zahlen habe ich 255 addiert, von größeren 255 abgezogen)

Wegstreckenzahl Checksumme (aus Dump) Checksumme (nach Formel) Differenz
3300 223 222 1
3325 173 172 1
3355 111 112 -1
3407 7 8 -1
3465 147 - 108 (+ 255 = 147) 0
3500 77 - 178 (+ 255 = 77) 0
3523 31 - 224 (+ 255 = 31) 0
3550 233 - 278 (+ 255 = - 23 / - 23 + 255 = 232) 1


Vielversprechend wie ich finde.

Nun für eine eigene K-Zahl: 3171 3171 * (-2) + 6822 = 480

480 ist größer als 255, also 255 abziehen:

480 - 255 = 225

Meine Checksumme ist also 225 (unsicherheit von +/- 1, siehe Tabelle oder mein vorheriger Post)

Das ist Hex lautet: E1

3171 in HEX lautet: 0C 63 -> Byteflip -> 63 0C

Im Dump ändere ich nun folgendes: (Ich gehe vom Dump der Codierung 01112 aus)

0x016 0x11C 0x11D 0x129 0x12A 0x12C 0x12D 0x12E 0x12F
alt 0x26 0x22 0x02 0x02 0x07 0x4F 0x0D 0x4F 0x0D
neu 0x26 0x00 0x00 0x02 0xE1 0x63 0x0C 0x63 0x0C

Dump ins KI geladen, KI macht einen Reset und der Tageskilometerzähler zeigt "0.0" - die Checksumme ist also korrekt. Fahrt mit GPS abgleich hat ergeben: KM-Zähler geht nun GPS genau (trotz deutlich größerer Reifen)

Falls es zu "dEF." kommt, bei die Checksumme +1 und -1 testen, siehe Ungenauigkeit weiter oben.



Die Codierung der Wegstreckenzahl in ist jetzt die "0" - lese ich das KI aus, sehe ich als Codierung daher: "01110". Testweise habe ich mal die Gurtwarnung (02) dazukodiert, also "03110". Die Null in der letzten Stelle bleibt erhalten, so auch die eigene Wegstreckenzahl (habe nach den Codierungen wieder ein Dump gezogen, die "63 0C 63 0C" bleibt erhalten).

Man muss die Codierung aber nicht auf 0 ändern. Es kann auch die vorherige bleiben, dann wird aber, auch wenn man etwas anderes codiert, die Wegstreckenzahl wieder mit dem überschrieben, was ursprünglich zur Codierzahl gehörte.




Zurück zur Übersicht