ODB2 und CAN beim Twizy... Es geht voran...

Joggls Sandhausen schrieb:

Ich finde die Theorie von Dexter bezüglich der Leistung-Traktionsbatterie (obere 12-bit der Bytes 3+4 der ID:0155) sehr schlüssig.

Nun zur Frage, was machen die restlichen 4 Bit der ID:0155/Byte3...

Hallo Uwe,

thx, aber ich meine die unteren 12 Bit von Byte 2+3

Meinst Du entsprechend die oberen 4 Bit von Byte 2?
Die sind aber bislang bei allen Logs konstant 9 = 1001b, oder?

...ich prüfe das noch einmal nach - auf jeden Fall bewegt sich der Byte 3 bei Belastung der 12V nach unten...

Das wird IMO einfach die normale Zusatzlast für den Traktionsakku durch den DC-Wandler sein, der ja den 12V-Kreis mit speist wenn der Twizy eingeschaltet ist.

Respekt vor der Leistung hier.

Zum "reverse engineering" vom Formeln und unbekannten Skalierungen benutze ich immer eureqa bzw. formulize. Hat mir schon oft weitergeholfen, vielleicht hilft es euch auch weiter:

formulize.nutonian.com/

Hi Don, das ist ein interessantes Tool, Danke für den Link.

Ein Problem ist dabei, dass wir noch nicht alle Messgrößen auf dem CAN-Bus gefunden haben. Evtl. bekommt man einige auch gar nicht oder nur indirekt, bspw. habe ich bislang kein Feld gefunden, dass den Blinkerstatus anzeigt. Oder man muss CAN-Requests senden um bestimmte Daten zu erhalten.

Wenn ich die konkrete Leitungsaufnahme wissen will, sollte ich dann 059B Byte 3 verwenden ? Das wären dann Werte zwischen 0 und 100% bzw negativ für Reku.
Oder gibt es da was mit konkreten Kilowatt angaben ? Hierüber liessen sich Tests/Optimierungen der Aerodynamik relativ einfach realisieren.

Hallo Klausz,

059B Byte 3 ist vermutlich kein Messwert sondern bereits eine Display-Aufbereitung, und außerdem recht grob aufgelöst.

Wir vermuten in 019F Byte 3+4 steckt der aktuelle Strom am Traktionsakku als 12-Bit-Wert, das wäre schon deutlich exakter und ein echter Messwert. Die Vermutung ist bislang nicht verifiziert und die Skalierung noch nicht ermittelt, aber da Du kannst Dich ja mal mit den Daten beschäftigen.

... leider gehts nicht mehr voran... was ich mit dem Twizplay festgestellt habe:

Bei Laden wird der Wert der prognostizierten Reichweite in km nicht aktualisiert - erst nach Einschalten der "Zündung".

Gruß, Uwe

Hallo Uwe,

ja, sorry... hab im Moment einfach keine Zeit zum Basteln / Probieren über. Mein OVMS-Modul liegt beim Zoll, hoffe bis das hier ist geht's wieder so gut wie bei Dir mit den unbezahlten Überstunden

Dumm dass die Prognose nicht beim Laden berechnet wird, aber die willst Du doch auch durch eine eigene ersetzen habe ich gesehen. Mit Deinem letzten Durchschnittsverbrauch und dem SOC kannst Du eine eigene Prognose berechnen. Evtl. brauchst Du neben dem aktuellen Verbrauch auch einen auf ein paar mehr km, hast Du genug persistenten Speicher dafür?

Alternativ, falls Du den letzten Prognosewert vor dem Ladestart speicherst, reicht das im Prinzip auch aus, wenn Du den jeweils mit dem steigenden SOC hochrechnest. Wird evtl. nicht so genau wie möglich sein, aber doch schon hilfreich.

Hurz...

Ich versuche gerade, meinem OVMS-Modul die Erkennung des Ladevorgangs und ggf. Ladeabbruchs beizubringen.

Leider war wohl die Vermutung bei ID 423 mit der Ladegerät-Aktivierung falsch, 0x03 scheint immer drin zu stehen solange irgendein System im Twizy aktiv ist, also auch schon bei Zündung an.

Ich habe gerade nochmal ein Testlog ausgelesen und finde nur einen Kandidaten: ID 597 Byte 1 scheint beim Laden auf 0x20 zu schalten, sonst 0x00. Das ist aber dann vermutlich eher der DC-DC-Wandlerstatus, weil 597 ja sonst wohl das 12V-Netz beschreibt, und die 0x20 scheint auch etwas "nachzulaufen".

Besser als nichts, aber hat vielleicht jemand von euch eine klare Erkennung der Ladegerät-Aktivierung gefunden?

dexter schrieb:

Hurz...

Ich versuche gerade, meinem OVMS-Modul die Erkennung des Ladevorgangs und ggf. Ladeabbruchs beizubringen.

Leider war wohl die Vermutung bei ID 423 mit der Ladegerät-Aktivierung falsch, 0x03 scheint immer drin zu stehen solange irgendein System im Twizy aktiv ist, also auch schon bei Zündung an.

Ich habe gerade nochmal ein Testlog ausgelesen und finde nur einen Kandidaten: ID 597 Byte 1 scheint beim Laden auf 0x20 zu schalten, sonst 0x00. Das ist aber dann vermutlich eher der DC-DC-Wandlerstatus, weil 597 ja sonst wohl das 12V-Netz beschreibt, und die 0x20 scheint auch etwas "nachzulaufen".

Besser als nichts, aber hat vielleicht jemand von euch eine klare Erkennung der Ladegerät-Aktivierung gefunden?

Hi Dexter,

vielleicht mache ich mir's zu einfach. Das Twizplay erkennt momentan die Ladung wenn:

- Die Geschwindigkeit auf 00 ist oder FF (FF steht auch mal drin)
- Und die Fahrstufe "N" ist
- Und ich eine positive Energiemenge erfasse (ID155 - Byte(2) und Byte(3))

Wenn die Ladung beendet wird und nicht mindestens 96% erreicht werden, dann kann man eine SMS schicken.

Was macht man aber, wenn man selber vorher ausstecken will - das OVMS hat halt keine Taster oder Anzeige - dann möchte ich keine SMS haben...

Gruß, Uwe

Hallo Uwe,

ich mach's mir bislang noch einfacher: die Fahrstufe spare ich mir, da ja bei ~0 km/h keine Rekuperation auftreten kann.

Ich finde mal eine SMS zuviel nicht so schlimm, dann weiss man auch dass alles funktioniert. Abgesehen davon wird der SMS-Weg ja eigentlich auch nur nötig sein wenn man die App nicht nutzen kann.

Noch ein kleines Update zum Thema Temperaturen

Ich verwende aktuell im OVMS folgende Interpretation, die prima passt + funktioniert:

1. 0x597 Byte 8 = Controller-Temperatur (OVMS: PEM = Power Electronics Module) in °F
2. 0x59E Byte 6 = Motor-Temperatur in °F
3. 0x554 Byte 1-7 = Batterie-Temperaturen der 7 Zellmodule in °F

Hab das eben auch im Objektverzeichnis so eingetragen.

Ich gehe aktuell davon aus, dass Modul 1 = Zellen 1+2, Modul 2 = 3+4 usw. -- muss nicht so sein, kann auch bspw. Modul 1 = Zellen 1+8 usw. sein, oder sonstwas... hab leider bislang keine eindeutigen Messwerte dafür/dagegen.

dexter schrieb:

Noch ein kleines Update zum Thema Temperaturen

Ich verwende aktuell im OVMS folgende Interpretation, die prima passt + funktioniert:

1. 0x597 Byte 8 = Controller-Temperatur (OVMS: PEM = Power Electronics Module) in °F
2. 0x59E Byte 6 = Motor-Temperatur in °F
3. 0x554 Byte 1-7 = Batterie-Temperaturen der 7 Zellmodule in °F

Hab das eben auch im Objektverzeichnis so eingetragen.

Ich gehe aktuell davon aus, dass Modul 1 = Zellen 1+2, Modul 2 = 3+4 usw. -- muss nicht so sein, kann auch bspw. Modul 1 = Zellen 1+8 usw. sein, oder sonstwas... hab leider bislang keine eindeutigen Messwerte dafür/dagegen.

Ja super! Das bringt mich an ganzes Stück voran... hat ein eingenes Screen im Twizplay verdient... 11 Temperaturen sollten ja reichen ;O)

Danke und Gruß, Uwe

Nachtrag: ich bin mir noch nicht sicher bzgl. der Temperatureinheit / -skalierung.

Aktuell hab ich den Eindruck sie liegen als Fahrenheit interpretiert einen Tick zu hoch. Bislang dachte ich das liegt an der Batterie-Isolierung, aber denkbar wäre auch eine zu F ähnliche Skala, bspw. ( Wert - 32 ) / 2 in °C, also gleicher Offset wie °F, aber Faktor 0,5 statt 5/9 = 0,555_.

Leider hab ich keine Ahnung wo die Sensoren genau verbaut sind, sonst könnte ich mal nachmessen. Leider hatte ich auch in den letzten Tagen zu wenig Temperaturbandbreite, aber das sollte sich nun ändern