(last Update: 12.03.08 09:00)
PROGRAMMIERUNG EIGENER WERTE DURCH ABFRAGE DER OBD-SCHNITTSTELLE
(this one is for runaways)
Diese Anleitung ist der Versuch, ein XGAUGE-Coding-Dokument in eine halbwegs verständliche Vorgehensweise zu "übersetzen".
Die Originalanleitung bietet hier leider gar keine Info über die einzelnen Parameter/Werte
Grundsätzlicher Aufbau eines XGAUGE Eintrags am Beispiel RPM (Drehzahl):
Der Aufbau besteht aus folgenden Werten:
TXD = COMMAND (in HEX)
RFX = XX XX | XX XX | XX XX (Filter des Antwortstrings / Formatierung des Ergebniswertes)
RXD = BB | BB (Position und Länge des Ergebniswertes im Antwortstring)
MTH = XX XX | XX XX | XX XX (Mathematische Aufbereitung des Ergebniswertes)
NAME = ABC (Anzeige im Gauge-Menü)
TXD = COMMAND (in HEX)
Der Aygo verwendet das ISO-Protokoll. Die gesetzlich vorgegebenen Werte (Mode 01) sind (hex) durchnummeriert. Die einzelnen Werte heißen PIDs. Alle Befehle beginnen 68 6A F1 01 , das letzte Byte ist der gewünschte Wert (PID).
BSP: RPM (Drehzahl) : COMMAND: 686AF1010C. Daraus folgt:
TXD = 68 6A F1 01 0C
Hinweis: der Aufbau des Antwortstrings kann überprüft werden, wenn man den TXD-Command im Menü COMMANDS eingibt.
Allerdings muß man dann aufpassen, ob der angezeigte Antwortstring wirklich zu dem Kommando gehört. (Das Gerät gibt einfach den nächsten Antwortstring aus, den es erhält...)
RFX = XX XX | XX XX | XX XX (Filter des Antwortstrings / Formatierung des Ergebniswertes)
Dieser Wert hat eine mehrfache Bedeutung.
Einerseits dient er zum Filtern der Ergebnisse,
andererseit bestimmt er Antwortformatierungen.
Dabei sind immer 2 Bytes zusammen zu betrachten.
1) Filtern des Antwortstrings über Offset/Match
Im Antwortstring ist der Mode und der Wert (PID) wieder enthalten.
Allerdings wird aus Mode "01" in der Antwort "41"
Es können max 3 Byte aus dem Antwortstring geprüft werden, min ein geprüftes Byte ist notwendig.
Die Prüfung erfolt in der Art "Ist das Byte mit dem Offset XX gleich dem Wert XX?"
BSP: RPM (Drehzahl) : ANSWER: 48 6B xx 41 0C ## ## xx)
Die ersten 3 Byte sind uninteressant, danach folgen Mode und PID.
Diese werden geprüft:
- ist Byte 04 = 41 ? (Mode "01" + "40")
- ist Byte 05 = 0C ? (PID "0C", der gesuchte Wert)
- eine weitere Filterung ist hier nicht notwendig.
Damit sieht der Filterwert so aus:
RFX = 04 41 | 05 0C | 00 00
Achtung: die Offset-Zählung beginnt bei Byte 1
2) Formatierung des Ergebniswertes
Folgende Sonderwerte für RFX sind definiert:
RFX = 8X XX | XX XX | XX XX : TRIP GAUGE / schon an anderer Stelle beschrieben
RFX = XX XX | 8X XX | XX XX : Wert wird mit Dezimalpunkt und einer Nachkommastelle ausgegeben
RFX = XX XX | 4X XX | XX XX : Wert wird mit Dezimalpunkt und zwei Nachkommastellen ausgegeben
RFX = XX XX | 2X XX | XX XX : Wert wird als ON/OFF ausgegeben
RFX = XX XX | XX XX | 8X XX : Wert wird HEX ausgegeben
(ich vermute, die Filter und Interpretation wird durch "AND" verknüpft.
Will heißen, aus Offset "05" und Interpretation "80" (Nachkommastelle)
wird der Wert "85". Ist an der Stelle einfach, weil einmal das höherwertige und einmal das niederwertige Nibble benutzt wird.)
RXD = BB | BB (Position und Länge des Ergebniswertes im Antwortstring)
Dieser Wert ist zweigeteilt.
-Byte 1 gibt die Stelle an, an der der Wert im Antwortstring beginnt.
Achtung: Zählung Bitweise beginnend mit Bit 0
-Byte 2 gibt die Länge des Wertes an, ebenfalls in Bit (in der Regel 8Bit oder 16Bit)
BSP: RPM (Drehzahl) : ANSWER: 48 6B xx 41 0C ## ## xx)
Der Wert beginnt bei Bit 28(hex) (6. Byte) und ist 10(hex) Bit lang. Also:
RXD = 28 10
(last Update: 12.03.08 09:00)
Beim Aygo beginnen die Werte im Anwortstring immer an der gleichen Stelle, und der Wert ist in der Regel 1 oder 2 Byte lang. Damit ist:
RXD = 28 08 für Werte mit 1 Byte oder
RXD = 28 10 für Wrte mit 2 Byte
MTH = XX XX | XX XX | XX XX (Mathematische Aufbereitung des Ergebniswertes)
Dieser Wert ist in 3 x 2 Byte zu teilen.
-Byte 1+2 geben den Mulitplikator an, mit dem der Wert multipliziert wird.
-Byte 3+4 geben den Divisor an, durch den das Ergebnis geteilt wird.
-Byte 5+6 geben einen (vorzeichenbehafteten) Summanden an, der zu dem Ergebnis addiert wird.
Im Beispiel ist der von der Schnittstelle ausgegebene Wert (per Definition) 4x so hoch wie die Drehzahl.
Also können folgende Werte verwendet werden: Multiplikator = 1 ; Divisor = 4 ; Summand = 0 . Also:
MTH = 00 01 00 04 00 00
(last Update: 12.03.08 09:00)
Eine "Verschiebung des Wertes" wäre über die letzten beiden Bytes möglich: (z.B. bei Temperaturwerten) z.B. Addition von "3" : "000x 000x 0003"
(Für eine Subtraktion von 3 läßt man den Windowsrechner umwandeln und erhält: -3 entspricht FF FD, also gesamt "000x 000x FFFD"
Ein prozentualer Fehler (z.B. Tacho) müßte über Multiplikation/Division behoben werden, z.B. (+3% = *103/100 oder *67hex/64hex) : "0067 0064 0000"
NAME = ABC (Anzeige im Gauge-Menü)
Glossar:
xX: HEX-Wert
BB: BINARY-Wert
Nochmal das Ergebnis des eigenen RPM-Wertes:
(es funktioniert, ich habe an diesem Beispiel die Funktionsweise erlernt...)
BSP: RPM (Drehzahl)
COMMAND: 68 6A F1 01 0C
(ANSWER: 48 6B xx 41 0C ## ## xx)
TXD = 68 6A F1 01 0C
RXF = 04 41 05 0C 00 00
RXD = 28 10
MTH = 00 01 00 04 00 00
NAME= R/M
Der so erstellte XGAUGE-Wert liefert exakt den gleichen Wert wie die interne Funktion RPM. (ist ja auch vermutlich die gleiche Abfrage
)
(last Update: 10.03.08 18:00)
WERTE (MODE 01), DIE DER AYGO LIEFERT:
Mode(hex) PID(hex) Data bytes returned Description Min value Max value Units Formula
01 00 4 PIDs supported Bit encoded [A7..D0] == [PID 0x01..PID 0x20]
01 01 4 Number of trouble codes and I/M info Bit encoded. See below.
01 03 2 Fuel system status Bit encoded. See below.
01 04 1 Calculated engine load value 0 100 % A*100/255
01 05 1 Engine coolant temperature -40 215 °C A-40
01 06 1 Short term fuel % trim—Bank 1 -100 (Rich) 99.22 (Lean) % 0.7812 * (A-128)
01 07 1 Long term fuel % trim—Bank 1 -100 (Rich) 99.22 (Lean) % 0.7812 * (A-128)
01 0B 1 Intake manifold pressure 0 255 kPa (absolute) A
01 0C 2 Engine RPM 0 16,383.75 rpm ((A*256)+B)/4
01 0D 1 Vehicle speed 0 255 km/h A
01 0E 1 Timing advance -64 63.5 ° relative to #1 cylinder A/2 - 64
01 0F 1 Intake air temperature -40 215 °C A-40
01 10 2 MAF air flow rate 0 655.35 g/s ((256*A)+B) / 100
01 11 1 Throttle position 0 100 % A*100/255
01 12 1 Sec.(?) air status Bit encoded. See below.
01 14 2 Bank 1, Sensor 1:Oxygen sensor voltage,Short term fuel trim 00 1.27599.2 Volts% A * 0.005(B-128) * 0.7812 (if B==0xFF, sensor is not used in trim calc)
01 15 2 Bank 1, Sensor 2:Oxygen sensor voltage,Short term fuel trim 00 1.27599.2 Volts% A * 0.005(B-128) * 0.7812 (if B==0xFF, sensor is not used in trim calc)
01 1C 1 OBD standards this vehicle conforms to Bit encoded. See below.
01 20 4 PIDs supported 21-40 Bit encoded
Zuletzt geändert von cdet am 12.03.2008, 11:51, insgesamt 3-mal geändert.
