SoC/Verbrauch-Fehler in Google Maps und ABRP

War heute mal wieder länger in NL unterwegs und dabei hat mich GM maximal genervt. Schaut euch mal dieses Bild an:

Symptom war wie folgt:
Route eingestellt und losgefahren mit 98% SoC. Müsste mit etwa 35% in Amsterdam ankommen. GM sagte zwar anfangs 17% bei Ankunft, aber das ist ja normal.

Irgendwann bei Hamminkeln ging der Ziel-SoC dann runter. Bis GM dann aufforderte, eine Ladestation auszuwählen. Das blöde Fenster geht auch nicht von selber weg. Es erfordert tatsächlich Aufmerksamkeit des Benutzers. Ziemlich unmöglich (und MMN in D auch OWi).
Spoiler: Bin tatsächlich mit 38% in AMS angekommen.
Die drei Routenalternativen, die ihr auf dem Bild seht, unterscheiden sich nur in einem wichtigen Punkt: Länge der Staus auf der Strecke. Berge und so sind ja in NL überschaubar (im doppelten Sinne). Irgendwann hat sich GM dann beruhigt und wieder vernünftige Werte angezeigt.

Aber auch auf dem Rückweg: Immer wieder zeigte GM Phantasiewerte für den Ziel-SoC an und wollte Ladestopp. Auch da waren Staus angezeigt.

Beim, sowieso geplanten, Ladestopp zeigte mir dann GM an, von den 25% auf mindestens 65% aufzuladen. Es erschien mir ziemlich viel, aber da ABRP in der gleichen Liga anzeigte, habe ich es dann mal gemacht.
Spoiler: Waren mindestens 20 Prozentpunkte mehr als nötig. Bin mit SoC 27% zuhause eingerollt.

Keine Ahnung, ob da Kausalität oder Korrelation im Spiel ist.

Hab auch parallel ABRP und CSV laufen lassen. Bei ABRP gab es den Effekt, daß der angezeigte SoC immer, bis auf wenige Sekunden, vom tatsächlichen abweicht. Irgendwann stimmt die Zahl überein, geht dann aber relativ schnell runter. Maximale wahrgenommene Differenz war 9 Prozentpunkte. Und dann springt ABRP wieder auf den richtigen Wert.

Der CSV hatte aber immer den richtigen Wert für den SoC.

Man kann also sagen: Beide Navigationsprogramme haben Probleme mit SoC, GM macht irgendwo massiven Mist bei der Verbrauchsprognose und ABRP ist nicht in Sync mit dem Auto. Aber CSV hat die richtigen Wert, also müssen sie verfügbar sein.
Wenn man von GM auf ABRP wechselt (boah, ist das langsam), dann sieht man kurz in ABRP den richtigen SoC. Sobald aber die Route angezeigt wird, steht da Müll.

Es gibt also irgendwo die richtigen Werte.

Was ist da schief?

Da ich mindestens drei GM Updates die letzten zwei Wochen gezählt habe und seit ein paar Wochen auf 2.7 fahre, gibt es da zu viele Variablen um es auf einen Schuldigen einzugrenzen.

Ich hatte ein ähnliches Verhalten als ein Stau auf der Route war, bei der scheinbar die Länge variiert hat. Deshalb ging der Ladezustand am Ziel plötzlich immer weiter runter.

Was bedeutet bitte CSV?

Car Stats Viewer. Siehe andere Threads hier im Forum.

Könnte darauf hinweisen, daß GM irgendwelche enormen Verbrauchswerte für Standzeit im Stau einrechnet.

Oder?

Vermutlich hat Polestar dann Google davon überzeugt den „super-tollen“ Standverbrauchswert aus dem RangeAssistent für die Verbrauchsberechnung im Stau zu verwenden… :stuck_out_tongue:

Möglich. Und da es in NL war, wurde angenommen, ich würde in den 30 Minuten Bitterballen frittieren, oder? Anders kann ich mir die 23 kWh „Phantomverbrauch“ nicht erklären.

Aber wo ist der CEE-Anschluß für die Fritteuse?

1 „Gefällt mir“

Aber jetzt also bitte… unübersehbar gleich links von der Not-Entriegelung des Ladekabels. :rofl::wink:

4 „Gefällt mir“

Ach ja. Da habe ich ja noch nie geschaut, weil das Kabel ja immer sauber entriegelt. Mea culpa.

1 „Gefällt mir“

Nicht empfehlenswert. Nach 5 Minuten sind sie schon fertig, nach 30 Minuten garantiert explodiert, mit entsprechender Sauerei in der Friteuse.

2 „Gefällt mir“

Dass ABRP mal ein paar Prozent beil SoC „daneben“ liegt (immer drunter, nie drüber), das kenne ich auch. Ich habe aber maximal 3 oder 4% Abweichung gesehen, definitiv nicht 9%.
Aus Interesse: Hast du in der Situation mal einen CD Reset gemacht?
Eine Erklärung für die Ursache habe ich nicht, aber der CD Reset wäre das einzigste, was mir als Therapie für die Symptome einfallen würde…

Ich schiebe das jetzt auf Google :stuck_out_tongue_closed_eyes:

Seit dem letzten Update bei GM (nicht im Auto oder App, sondern zentral bei Google im System)
Habe ich auch lustige Sprünge im Ziel-SOC

Bei Abfahrt +17,
dann schlagartig -20,
zurück auf +15,
usw …
Am Ende stimmt’s dann meist.

Und jetzt wo ihr es erwähnt, da waren immer Staus angezeigt, die dann gar nicht da waren :thinking:

Finde auch das Google oder wer auch immer Recht pessimistisch rechnet. Sehr ärgerlich wenn man mit 9 % mehr am charger ankommt… Aber vielleicht auch gut. Somal ich mit Tempomat vorher 180 km konstant gefahren bin. Verstehe die Schwankung nicht so Recht. Bin auch nicht dauerhaft bergab oder so 🙋 . Naja gibt schlimmeres.

Edit… Hmmm Ja die Ankunftszeit was oftmals orange… 🙋 Interessant

Hab keinen CD-Reset gemacht. Kann mir auch nicht vorstellen, warum das etwas ändern würde. Der CSV hatte ja die richtigen Werte.

Man kann sehen (konnte halt beim Fahren nicht filmen), daß beim Wechsel vom CSV zu ABRP erstmal der richtige Wert angezeigt wird. Dann baut sich die Route auf und dann kommt eine neue Darstellung, in der ein falscher Wert steht. In Intervallen scheint ABRP dann wieder einen Absolut-Wert zu laden und dann stimmt kurzzeitig der Wert, um dann zügig wieder abzudriften.

Ganz so, als ob ABRP den richtigen Wert nur alle paar Minuten abfragt und dazwischen auf Basis irgendwelcher anderen Werte (Strecke mal ermittelter Verbrauch?) was extrapoliert, was nicht so richtig funktioniert.

Meine Frau meinte, daß es eventuell eine NaN-Situation in der Google-Kalkulation ist. Im Stau ist ja evtl. Tempo 0 und wenn GM irgendwo die Geschwindigkeit als Divisor nutzt, könnte sowas entstehen, wenn es nicht abgefangen ist.

Ich hatte auch vor drei Wochen die interessante Planung bei GM, dass vor dem losfahren alles okay ist 10% Puffer und wenn man dann die Navigation startet stand da -X Prozent. Die kamen dann mit der Zeit wieder. Ich bin dann mit dem ursprünglich prognostizierten Prozentsatz angekommen. Apropos mir ist aufgefallen, dass wenn man sich an ein Ladenetz wie Ionity hängt zum Teil komplett anders fährt wie wenn man hm nur als Verbrenner nutzen würde.

Welchen Wert meinst du denn hier? Ein Ziel-SoC ist mir im CSV nicht bekannt.

Ich hatte eine ähnliche Erfahrung letzte Woche. Nach dem Schnellladen sollte ich mit 11% ankommen (etwas zu lange geladen :grin:) aber nach einigen Metern Fahrt wurde daraus plötzlich 1%. Dann nochmal 1 km weiter gefahren und Ziel-SoC sprang auf 11% zurück. In der Zeit wo es 1% anzeigte, hatte ich auch eine komische Leistungsbegrenzung (schraffierte Fläche) was ich eigentlich nach dem Laden nicht erwarte. Also irgendwas hat da gesponnen.

Im Zusammenspiel mit CSV und aktiver Anbindung an ABRP (ab Version 0.24) könnte ich mir schon vorstellen, dass es da evtl. zu Ungereimtheiten beim Datenmanagement kommt.

a) ABRP fragt ja den Wert ab und bewertet ihn
b) jetzt kommt CSV und gibt ABRP „zusätzliche“ Werte, die ja irgendwie verarbeitet werden müssen.

Bis diese Verarbeitung erfolgt, könnte ich mir Datenmüll vorstellen.

Was ich mir aber nicht vorstellen kann ist der Datenmüll von GM, denn da kommen ja keine zusätzlichen Werte an.

Es würde mich wundern, wenn das Probleme machen würde :thinking: ABRP nimmt ja lediglich Momentanwerte entgegen, keine Zeitabhängigen.

Ich weiß nun natürlich nicht, wie ABRP die Daten verarbeitet, aber im Prinzip wäre es einfach eine Verdopplung der Abtastrate, wenn beides läuft. Seit kurzem zeigt ABRP ja auch beide Datenquellen unabhängig voneinander an. Da würde es mich wundern, wenn sich die Server da verrechnen würden.

image

„Api“ ist in diesem Fall CSV

Das einzige, was ich mir auf Grundlage dieser Aussage vorstellen könnte, ist, dass ABRP einige Gedenksekunden braucht, um den aktuellen SoC zu erkennen. Die App läuft ja nicht im Hintergrund, sondern ausschließlich im Vordergrund. Wenn die App dann ne weile im Hintergrund war, hat sie noch einen alten SoC im Speicher, bis der aktuelle eingetrudelt ist (entweder direkt vom Auto oder über den Server den zuletzt von CSV übermittelten Wert).

1 „Gefällt mir“

Den aktuellen SoC, den ABRP in diesem Fall ja falsch anzeigt.

Das glaube ich nicht. Denn von ABRP anfangs angezeigte SoC ist der korrekte, nicht der aus dem Speicher.

Wenn auf ABRP zurück gewechselt wird, kommt erstmal weiße Seite, dann das ABRP-Logo, dann baut sich Karte auf und dann kommt links unten der aktuelle SoC. Das ist der richtige Wert. Dann lädt ABRP die laufende Route und zeigt links unten das Status-Fenster (Ziel-Zeit, Anteil gefahrene Strecke, Ziel-SoC und „aktueller SoC“) an. Dort ist der aktuelle SoC dann falsch. In meinem Fall immer niedriger als der richtige SoC. Wäre das ein gespeicherter Wert, müsste er ja gleich oder höher als der richtige SoC sein, wenn man nicht zwischendurch geladen hat.

Will ja hier eigentlich nicht das ABRP-Problem lösen. Fand es halt komisch, daß sowohl GM als auch ABRP Müll anzeigen. GM zeigt ja nur den Ziel-SoC an, ABRP aber aktuellen und Ziel-SoC und da ist der aktuelle falsch, woraus auch falscher Ziel-SoC resultiert. Gleichzeitig zeigt CSV aber immer den richtigen SoC an.