Anleitung: obd auslesen ohne obdeleven

@dexter bezüglich PID 22 02 BD (8C) 'standard ambient conditions' :

Code: Alles auswählen

  MAS00464-MAS00106   Standard - ambient data 1-Year 2058
  MAS00464-MAS00107   Standard - ambient data 1-Month 14
  MAS00464-MAS00108   Standard - ambient data 1-Day 30
  MAS00464-MAS00109   Standard - ambient data 1-Hours 19
  MAS00464-MAS00110   Standard - ambient data 1-Minutes 15
  MAS00464-MAS00111   Standard - ambient data 1-Seconds 27
  MAS00464-MAS00468   Standard - ambient data 1-Unlearning counter 123
  MAS00464-MAS00711   Standard - ambient data 1-Odometer reading 53754 km

https://forums.ross-tech.com/index.php? ... ost-233732

Fällt dir was auf?

[dexter]

Die Timestamp-Kodierung würde so Sinn ergeben:

(Zero indexed:)
Year: start from byte 0, bit 2, 6 bits long
Month: start from byte 1, bit 6, 4 bits long
Day: start from byte 1, bit 1, 5 bits long
Hour: start from byte 2, bit 4, 5 bits long
Minute: start from byte 3, bit 6, 6 bits long
Second: byte 4, 6 bits

Das ist dann das folgende Bitlayout, damit kann ich aber auch nur eine valide Uhrzeit bekommen, die Datumswerte sind sowohl in 02BD als auch in den DTCs komplett daneben.

Code: Alles auswählen

  23 8a 91 63       (28.7. 09:02:35)
  00100011 10001010 10010001 01100011
  yyyyyymm mmdddddH HHHHMMMM MMSSSSSS
                  ^_09_^^_02__^^_35_^

Byte 0 von 02BD ist dann wohl der Verlernzähler, und DTC-Detail 02 enthält einen Snapshot von 02BD.

Bytes 4+5 von 02BD finde ich gerade sehr spannend, könnte das ein Degradationswert sein? Korreliert lose mit der Laufleistung:

Code: Alles auswählen

  Fzg M     km   151  → 0x0000      0
  Fzg M     km  2873  → 0xfff2    -14
  Fzg C     km 11646  → 0xffc8    -56
  Fzg H     km 19532  → 0xffba    -70

Mit Bytes 4+5 hab ich mich noch nicht befaßt, die sind bei mir aber entweder '00 00', 'FF F4' oder 'FF F2' und ein paar mal waren sie '31 34'

Ich denke ich habe das "Datum" geknackt, das ist kein Datum sondern ein Zähler der Tage seit dem Produktionsdatum, das Format ist aber sehr merkwürdig:
Von deiner Darstellung sind es folgende bits: yyyyyy____ddddd
Die mmmm bits sind bei mir seit Ende April seitdem ich diesen PID tracke immer fest auf '1110', während bei den yyyyyy bits jedesmal 1 addiert wird sobald ddddd überläuft. Mit 11 bits wird dieser Zähler aber in ca. 5,6 Jahren überlaufen, weiß nicht was dann passiert.

Ich sehe gerade, meine Tageszähler Dekodierung funktioniert auch beim Beispiel oben vom Rosstech Forum:
"Year" 2058 ist 2000+58 also 58=111010 binär,
"Month" 14 entspricht den '1110' die ich auch immer in den bits sehe und die anscheinend nicht zum Zähler dazugehören,
"Day" 30 = 11110 binär,
also sind die 11 bits 11101011110 (yyyyyyddddd) was 1886 Tage sind. Im ersten Beitrag in dem Rosstech Thread sagt der TS das der e-up aus 2016 ist, 1886 Tage sind knapp über 5 Jahre. Bingo!

Byte 0 von 02BD ist dann wohl der Verlernzähler, und DTC-Detail 02 enthält einen Snapshot von 02BD

Ja, so sehe ich das auch.

[dexter]

Die Interpretation als Tageszähler bei Ausblendung der vier "Monatsbits" liefert auch bei mir konsistente Ergebnisse. Die Referenz ist aber offenbar nicht das Produktionsdatum, denn bei mir kommt der 9.11.2020 heraus. Der passt bei mir zu nichts so richtig:

viewtopic.php?p=1586672#p1586672

Könnte der Tag der Endkontrolle o.ä. gewesen sein, aber in PIDs tauchte der sonst noch nicht auf. Monat "14" ist dann evtl. einfach die Markierung für dieses Format.

[dexter]

Hab den 9.11.20 doch gefunden, nur nicht in dem SG. In den anderen steht der Wert teils in F17B, und teils in F1A9, oft in beiden. Bei SG 01 steht er 4x in F15B, aber weder in F17B noch in F1A9.

Code: Alles auswählen

773[7dd]:f17b 20 11 09
773[7dd]:f1a9 20 11 09

7e0[7e8]:f15b 20 11 09 00 00 09 a6 7a b6 00 20 11 09 00 00 09 a6 7a b6 00 20 11 09 00 00 09 a6 7a b6 00 20 11 09 00 00 09 a6 7a b6 00

Die Referenz ist aber offenbar nicht das Produktionsdatum, denn bei mir kommt der 9.11.2020 heraus. Der passt bei mir zu nichts so richtig:
Könnte der Tag der Endkontrolle o.ä. gewesen sein

Letztlich ist es egal welcher Tag der Referenztag ist. Wir brauchen den Tageszähler ja nur um das Datum von jedem DTC auszurechnen, und dafür müssen wir ja nur die Differenz zwischen dem Tageszählerwert im PID 22 02 BD und dem Wert in den extended data vom DTC vom aktuellen Datum abziehen.

Monat "14" ist dann evtl. einfach die Markierung für dieses Format.

Ja, gut möglich das der Wert als Markierung gedacht ist.

Ich frage mich allerdings was passiert sobald der 11-bit Tageszähler überläuft, also sobald das Auto mehr als ca. 5,6 Jahre alt wird. Eventuell ändert sich dann der "Monat" auf 15 (und nach 11 Jahren dann möglicherweise auf 00).

Um das zu klären wäre es schön wenn wir den PID 22 02 BD bei einem e-up von 2013-2015 auslesen könnten, kennst du da eventuell eine Möglichkeit unter den OVMS Usern?

[drilling]

Ok, ich mach hier weiter, da es besser hierhin paßt.

E-lmo EZ 4/2015: 23 23 97 39 43

Das ergibt beim Tageszähler 267. Wenn man 2048 dazuaddiert paßt es: 2315 Tage -> 28/03/2015
Allerdings ist der "Monat" weiterhin 14 also kann man nicht wissen das der Tageszähler übergelaufen ist und wieder von Null angefangen hat.
Also muß man noch ein Datum von einem anderen PID hinzuziehen um den Tageszähler richtig zu interpretieren. Das hätten sie wirklich einfacher machen können.

@dexter Mir fällt gerade auf Frederik schrieb ja das das "Jahr" 7 bits lang sein soll und das der Timestamp insgesamt 5 Bytes benutzt, d.h. das erste bit von ff könnte noch zum Tageszähler dazugehören und das ist nur bei E-lmo auf 1 gesetzt, bei mir ist das immer 0 und bei dir und marxx anscheinend auch.
Was meinst du?

[dexter]

Könnte sein, ja. Aber wir bräuchten mehr Samples…