Priusfreunde.de

lexel schrieb:
Die Formel Formel (A * 256 + B ) / 8 - 4096 scheint nicht zu stimmen. Schreibt ja auch jeder von jedem ab ... Nein, ich teste auch. Nur leider habe ich keinen Auris II HSD TS hier. Beim Auris I HSD hat obige Formel mit Torque funktioniert. Ich habe Aufzeichnungen mit plausiblen Werten. Vielleicht hat sich beim Auris II TS doch etwas geändert (ich vermute du sprichst von diesem Modell)?

Zweistellige Werte wären übrigens in Nm normal. Nur beim Anfahren und Bremsen kann es dreistellig werden.

Ich glaube dir das es für den Auris I geht, ist aber auch andere Adresse.

Beim Auris II HSD den ich habe (=gleiche Adresse wie Prius 3) scheint etwas anders zu sein. Wenn ich die Adresse auslese steht:
61 68 80 00 80 00 00 (in Ruhe) und wenn ich fahre verändert sich das auf Bsp. 61 68 80 BC 80 B3 00
Wenn zweistellige Werte normal sind dann dürfte die Original Scangauge II Methode in ft lbs vlt stimmen. Aber die Entwickler haben doch metrische Einheiten verwendet?
So hatte ich es drin
TXD: 07E22168
RXF: 046105680000
RXD: 2810
MTH: 00010008F000
NAM: M2T
Unit: Nm
steht 3580 in Ruhe . Totales Rätsel

lexel schrieb:
Ich glaube dir das es für den Auris I geht, ist aber auch andere Adresse.Auris I HSD hat auch die gleichen Adressen wie P3.
Aber die Entwickler haben doch metrische Einheiten verwendet?Ja der Wert im Telegamm ist metrisch, wie der Faktor 0,8 beim ft-lbs X-Gauge reinkommt, habe ich oben erklärt.
61 68 80 00 80 00 00 (in Ruhe) und wenn ich fahre verändert sich das auf Bsp. 61 68 80 BC 80 B3 00Danke für die Darstellung der Telegramminhalte, das hat mich auf eine Idee gebracht: Ist es ein Vorzeichenproblem? Die 8000 hex im Telegamm bei Stillstand sind ja als +32768 dezimal zu interpretieren (nicht -32768). Die Scangauge-Doku sagt dazu:
The Multiplier is a 2 byte value to multiply the data by. The resulting data must not be larger than 4 bytes and the upper bit must be 0 if the resulting value is not a negative value.

The Divider is a 2 byte value to divide the results from the multiply by.

The Add/Subtract adds the 2 byte value to the results from the multiply and divide. This is a signed value. If the upper bit is set, the value is the two's compliment negative value. If the result has the highest bit set, the response will assume it is a two's compliment negative value and will show it as a negative value. Some care is required to avoid unintentionally setting or clearing this bit through an add/subtract operation and changing the sign of the displayed value. This can be done by scaling the value properly using the multiply and divide before doing the add/subtract.
So ganz verstehe ich dann trotzdem nicht, wieso bei RXF 046105680000 / MTH 00010008F000 dann im Stand 3580 rauskommt. Wenn der SG die 8000 hex als negativ interpretiert, dann müsste nach Division durch 8 doch F000 hex rauskommen. Dazu dann F000 hex addiert ergibt E000 hex = -8192 dezimal.

Ich hätte folgende Idee: Man nimmt noch ein Bit vor den 8000 hex dazu. Das Bit ist zum Glück immer 0 (das Byte ist 68 hex). Ich hoffe SG kann mit 17 Bit rechnen, aber zu irgendwas muss es ja gut sein RXD in Bits angeben zu können. Das ergibt dann:

TXD: 07E22168
RXF: 046105680000
RXD: 2711
MTH: 00010008F000
NAM: M2T
Unit: Nm

Edit: Mir ist eingefallen: Falls das mit den "ungeraden" Bitgrenzen funktioniert, dann könnte man statt durch 8 zu teilen auch gleich die letzten drei Bits weglassen. Ergibt dann:

TXD: 07E22168
RXF: 046105680000
RXD: 270E
MTH: 00010001F000
NAM: M2T
Unit: Nm

proprius schrieb:


TXD: 07E22168
RXF: 046105680000
RXD: 2711
MTH: 00010008F000
NAM: M2T
Unit: Nm

Edit: Mir ist eingefallen: Falls das mit den "ungeraden" Bitgrenzen funktioniert, dann könnte man statt durch 8 zu teilen auch gleich die letzten drei Bits weglassen. Ergibt dann:

TXD: 07E22168
RXF: 046105680000
RXD: 270E
MTH: 00010001F000
NAM: M2T
Unit: Nm

Vielen Dank für Deine Mühe!

Habe gleich beide Varianten probiert und es kommen in beiden Fällen die gleichen kleinen Werte heraus.

Beim Rückwärtsfahren wird übrigens quitiert 61 68 7F 25 7F 2F 00
Denke daher 8000hex ist die Basis also oder Nullwert. Darunter negatives Torque und drüber positive Torque Werte.

lexel schrieb:
Denke daher 8000hex ist die Basis also oder Nullwert. Darunter negatives Torque und drüber positive Torque Werte.Schade, dass es nicht funktioniert. Das erklärt den merkwürdigen Hack mit ft-lbs + 8%. Ja, das Drehmoment kann negativ werden und 8000 hex ist der Nullwert. Echt saublöd, dass SG keine Möglichkeit hat anzugeben, ob es im Telegramm mit oder ohne Vorzeichen steht.

Weitere Möglichkeiten, die mir einfallen: Falls man im SG 3 Byte nehmen kann, dann nimmt man das Byte davor komplett dazu. Dann multipliziert man mit 8192. Dadurch fallen alle Bits von 68 hex im 32 Bit Ergebnis oben raus. Es bleiben nur die unteren 3 Bits von 68 hex übrig, die sowieso 0 sind. Jetzt wird es kifflig: Man müsste eigentlich durch 65536 (= 8192 * 8) teilen. Das passt nicht in die 2 Byte für den Divisor. Wenn man minimale Fehler akzeptiert, könnte man durch 65535 (=FFFF hex) teilen. Die Frage ist, ob der SG FFFF wieder als Zweierkomplement (-1 dezimal) ansieht. Alternativ könnte man durch 6554 (199A hex) teilen und zusätzlich im RXF noch die Division durch 10 aktivieren. Das Problem dabei: Die Addition/Subtraktion wird ausgeführt, bevor am Ende nochmal durch 10 geteilt wird. Also müssten wir statt 4096 auf einmal 4096 * (65536 / 6554) = 40957 abziehen. Leider ist -40957 nicht als 16 Bit inklusive Vorzeichen darstellbar. Glück könnte man haben, wenn die Rechnung in 16 Bit mit Überlauf ausgeführt wird und die Bits oberhalb von 16 einfach verworfen werden. Denn dann könnte man auch einfach 6003 hex (= -40957, wenn man die Bits über 16 verwirft) addieren.

Möglichkeit 1:

TXD: 07E22168
RXF: 046105680000
RXD: 2018
MTH: 2000FFFFF000
NAM: M2T
Unit: Nm (Fehler: 0,0015 %, falls es klappt)

Möglichkeit 2:

TXD: 07E22168
RXF: 046185680000
RXD: 2018
MTH: 2000199A6003
NAM: M2T
Unit: Nm (Fehler: -0,0061 %, falls es klappt)

Bin ja gespannt was ihr herausbekommt.

Offensichtlich wurde mir bisher mit der folgenden Abfrage im SG2 falsche Nm-Werte von MG2 angezeigt:
TXD: 07E22168
RXF: 046185680000
RXD: 2810
MTH: 000100018000
NAM: M2T
Gehe ich recht dass der lbf-ft-Wert mit 1,36 multipliziert werden sollte um zu Nm zu kommen?

Dann stimmt wohl der entsprechende xgauge für den MG1 ebenfalls nicht?

Werde den Thread gespannt weiterverfolgen. Viel Erfolg bei der Lösung, zu der ich wegen persönlicher Inkompetenz leider nichts beitragen kann .

Gruß alupo

proprius schrieb:


Möglichkeit 1:

TXD: 07E22168
RXF: 046105680000
RXD: 2018
MTH: 2000FFFFF000
NAM: M2T
Unit: Nm (Fehler: 0,0015 %, falls es klappt)

Möglichkeit 2:

TXD: 07E22168
RXF: 046185680000
RXD: 2018
MTH: 2000199A6003
NAM: M2T
Unit: Nm (Fehler: -0,0061 %, falls es klappt)

Danke. Leider funktionieren beide Methoden nicht, es kommt immer ein einstelliger Wert heraus. Bei beiden Methoden gleich.
Wenn wir das knacken sind wir wohl die ersten weltweit die mit dem Scangauge II das Tourque in Nm für dieses Auto richtig anzeigen

Kanne es sein dass mit Math 000100018000 überhaupt bereits das Drehmoment in Nm angezeigt wird und nicht in ft-lbs.
Wenn ich Entwickler wäre, wäre das die einfachste Berechnung, denn warum sollte man das anderst kompliziert machen? (ich weiß dass auf der Scangauge II Homepage ft-lbs steht).
Muss das anzweifeln.

Mit meinen Einstellungen (siehe weiter am Anfang) habe ich heute zumindest einen Wert für MG2 von knapp 90 gesehen.

Zumindest nicht völlig abwegig, oder?

Hier eine Torque-Aufzeichnung vom Auris I HSD über eine knapp dreistündige Autobahnfahrt. Man sieht, dass das MG2-Drehmoment (blaue Linie) meist zwischen +/- 20 Nm liegt und nur einige Ausreisser nach oben und unten hat. Meist nur dann, wenn der Verbrenner nicht läuft.


@lexel: Ohne die Division durch 8 sind deine Werte eben 8 mal größer. Das sollte auffallen. Beim P2 sind es übrigens tatsächlich ganze Nm, aber beim THS 3 wollte Toyota es wohl besonders genau machen. (Edit: das ist natürlich Blödsinn. Auch beim P2 war es schon durch 8 geteilt, nur lag der Nullpunkt bei 4000 statt 32768.) Ich bin etwas ratlos. MTH scheint sicht nicht so zu verhalten, wie man es erwarten würde. Man kann jetzt eigentlich nur noch probieren durch verschiedene MTH-Werte herauszufinden wie der SG wirklich rechnet. Ich bin zumindest froh, dass mir dieses Problem bewußt geworden ist.

@alupo: Mit dem X-Gauge in ft-lbs + 8% muss man mit 1,25 multiplizieren um auf Nm zu kommen. "persönliche Inkompetenz" haha, Kopf hoch, das ist keine Kompetenz, die vom Durchschnittsmenschen erwartet wird. Ich mache solche Bit-Schubsereien schon seit Jahrzehnten als Hobby und Beruf .

Vielen Dank!
Die Grafik ist hilfreich auch wenn du Autobahn gefahren bist (hoffentlich)
Diese und ähnliche Werte bringt die Methode von Scangauge II dürfte vermutlich also stimmen.

Ich habe eine Idee mit MTH 00080040F000 also mit 8 multiplizieren und durch 64. Vlt geht der Trick muss ich morgen testen.

Heureka ich habs!
Scheint zu klappen
Torque MG2 Toyota Auris II (Prius 3):
TXD: 07E22168
RXF: 046105680000
RXD: 2810
MTH: 00080040F000
NAM: TM2
in Nm ohne Komma

sg
lexel

Hallo zusammen!
Als neuer Prius III-Besitzer (gut, es ist nur ein gebrauchter) wollte ich letzte Woche meinen Scangauge II mal anschließen, der 2 Jahre unbenutzt in der Ecke lag. Ich hatte ihn vorher an einem Ford Focus Diesel, wo er leidlich funktioniert hatte.
Kaum angeschlossen, kam auch schon der große Schreck!
Zwei Warnlampen gingen im Display an (Hybridsystem überprüfen) und das Ausrufezeichen leuchtete gelb.

Der Wagen ist aber ganz normal gefahren (obwohl die Anleitung sagt, man solle ihn abstellen und eine Toyotawerkstatt kontaktieren) und nach 3 Tagen ist die Meldung von selbst verschwunden.

Jetzt die Frage an die Experten: woran kann das liegen? Hatte jemand schon mal ein ähnliches Problem? Waren in dem Scangauge vielleicht noch falsche Parameter vom Ford hinterlegt? Hatte versucht, den Kontakt zum Bus per "Force"-Funktion herzustellen, da die Synchronisierung nicht gleich geklappt hat. Welches Protokoll wäre das richtige gewesen?

Vielen Dank für Hinweise in dieser Sache!

@energiesparer: Setze mal auf Werkseinstellungen zurück und stelle dann alles neu ein. Suche im Internet ergabe folgende Menüfolge für den Reset: More > More > More > Use Defaults

Hallo proprius!

Ja, danke für den Hinweis!
Werde ich bei Gelegenheit mal probieren.
Ich hatte schon das Anschlusskabel im Verdacht.