Ggf. behebt ja diese 3.5.3 das Problem schon
nein:
"Mit der Over-the-Air-Feldmaßnahme (OTA): OUM1 „ME 3.5.3“ wird die Leistungs- und Steuerelektronik für Elektroantrieb (Diagnoseadresse: 0051) bei Fahrzeugen mit Softwarestand „ME 3.5.2“ aktualisiert"
Die vorderen H&R Federn sind übrigens bei allen Born identisch, nur die Hinterachse ist unterschiedlich.
schlimm genug, dass bis jetzt (für bis MY2024) bei H&R die HA mit einer einheitlichen Feder bedient wurde 
Mit der erhöhten Achslast der HA ist diese "Krücke" nun überhaupt nicht mehr haltbar.
Da waren andere Hersteller schon lange besser aufgestellt...
Aus meiner Sicht ist das VW-Konstrukt eine Totgeburt!
Janein..
Stellt euch mal auf die andere Seite des "Geldverdienens":
Die OEMs müssen für eine bestimmte Zeit und Laufleistung einen bestimmten Rest-SoH garantieren (!!).
Dieser basiert nunmal auf Basis eines mittleren Verbrauchs und damit auf einer bestimmten Anzahl von Ladezyklen und sind z.T. jetzt schon schwierig zu gewählleisten.
Z.B. würde ein hauptsächlicher Anhängerbetrieb eines BEV die Anzahl der Ladezyklen und der ge- und entladenen Energiemenge nahezu verdoppeln lassen.
Sinkt der SoH bei einer solchen Betriebsart vorzeitig unter die gefestgelegten Grenzen, bin ich auf die Diskussionen gespannt..
Und V2G stellt durchaus eine vergleichbare, zusätzliche Belastung für den Akku dar, wenn man sie nicht entsprechend begrenzt.
Also aus OEM-Sicht:
"Warum soll er mit "seiner Garantie" für etwas garantieren, für dass er (!) die Batterie überhaupt nicht ausgelegt hat?"
(u.A. ist hier der Grund zu suchen, warum VW BiDi nicht für die kleinen Batterie freigegeben hat und die BiDi Leistungen für die grossen entsprechend einschränkt).
Von dem Vorgehen kann man halten, was man will, aber betriebswirtschaftlich ist es zu 100% zu verstehen.
btw.:
die derzeitigen AC-BiDi V2L Fahrzeuge haben iDR deutlich eingeschränkte Entladeleistungen oder deutlich grössere (LFP-) Batterien, warum die Energiemengen im Vergleich zum Verbrauch geringer ist.
Wie ist das beim bidirektionalen Laden, genauer gesagt wenn ich den Strom aus dem Auto ziehe, muss da nicht dauernd die Elektronik im Auto an sein, so wie beim laden? Die braucht ja um die 300W.
Auch wenn hier einige VW entsprechenden Weitblick absprechen wollen, hat VW diesbezüglich schon vollumfänglich gedacht und das System entsprechend umgesetzt:
Wird im ZündungsZykel-Betrieb (Klemme15 = an) etwa 300W allein für den Betrieb aller Steuergeräte verbraucht, wird bei AC- und beim DC-Laden das Fahrzeug "ausgeschaltet" und nur die notwendigen Steuergeräte an den hierfür notwendigen Busssystemen betrieben.
Entsprechend reduziert sich der Fahrzeugenergiebedarf wärend des DC-Lades z.B: auf 150W
Muss ich mir vielleicht doch einen Ioniq 5N kaufen. Der kann AC. -.-
Vorsicht!
Hier zwingend die Betriebsanleitung genau beachten.
Hyundai u.a. unterstützen nur V2L nicht V2G
Der Unterschied liegt halt genau in der Frequenzangleichung der BiDi-Funktion an das Versorgungsnetz. Dies muss der OBC unterstützen, damit er an Netz angeschlossen werden darf.
Und das machen derzeit die wenigsten BiDi-OBC und unterstützen entsprechend nur V2L.
Beim DC-Bidi obligt diese Funktion der Wallbox und nicht mehr in der Verantwortung des Fahrzeug-OBC.
Ein Grund, warum VW auf DC-BiDi setzt..
Auch wird u.A. aus Kostengründen disktuiert, das AC-Laden zu eliminieren und nurnoch auf DC-Laden zu setzen.
Wenn ich dann zuhause geladen werden soll, wird eine DC-Wallbox benötigt, die dann problemlos DiBi unstützen kann.
das Zusammensuchen der Informationen hat etwas gedauert, aber jetzt ist das Bild klarer;
Könnte es aber sein, er schon ABT 6091 vorm Update hatte, da sein Produktionsdatum am 27.04.23 ist?
die 6091 ist mit der SWV 3.5 ausgerollt worden. Das kann mit dem Produktionsdatum passen.
Auch kann das OTA-Upate auf die SW3.5 angewendet werden, die Anzahl der zu flashenden Steuergeräte reduziert sich entsprechend, damit sich der SWV3.5.2 ergibt.
Also ja: das muss der Grund sein..
Die TPI für 3.5.3 ist vlt. nicht korrekt.
Die TPI ist korrekt, aber jetzt wird es leider kompliziert:
Bis jetzt habe ich keine andere 6085>6091 Update in den MeinID/Skoda/Cupra Foren gemerkt und zumindest vor 6 Wochen gab's noch keine Flashdatei für 6091.
Denn auch dies ist richtig:
eine SW 6091 ist derzeit für das ABT auf dem Mirror-Server AFAIK nicht zu finden.
Noch schlimmer:
das Werkstatt-Update, welcher der TPI zugrunde liegt, versucht tatsächlich die SW 6091 zu flashen, findet aber den o.g. Flashcontainer nicht und bricht entsprechend ab 
Offensichtlich war es geplant die SW6091 mit dem OTA Update auszurollen, aber aus mir nicht bekannten Gründen, hat man den Softwareverbund noch einmal geändert spielt jetzt die SW6085 ein, sowie sie nicht schon auf dem ABT ist. Die TPI basiert aber noch auf dem alten Stand und agiert auch mit dessen Planung.
Damit sind auch die Anstrengungen zu erklären, die dahle ´s Werkstatt hatte, den Offline Flashprozess durchzuführen, der den SWV 3.5.3 auf sein Auto bringen sollte.
In wieweit die SW6091 für das ABT jetzt im Nachgang aufgespielt wird und der entsprechende Flashcontainer auf dem Mirror-Server verfügbar ist, kann ich nicht sagen.
Möglicherweise wird auch der hinter der Massnahmencode hinterlegte SWV der TPI angepasst.
Die Auswirkungen, die das Verbleiben auf der ABT-SW6085 müssen bei Cupra nicht den gleichen entsprechen, die es bei VW hatte.
Dort hat ein (zu-) häufiger Check des Komponentenschutzes die Kommunikation zwischen ICAS3 und ABT abgebremst.
Nach dem Softwareupdate waren entsprechend deutliche Performancesteigerungen bei der Bedienung zu spüren.
Das muss aber bei Cupra nicht zwingend der Fall sein, wenn entsprechend seltener der Komponentenschutz abgefragt wird.
Auch weiss ich nicht, ob bei VW die SW6085 beim OTA-Update aufgespielt wird, die Systemanzeige ist hier diesbezüglich deutlich eingeschränkter und ein Steuergeräte-Scan im ID.3 mit OTA auf SW3.7 ist mir noch nicht zugesendet worden.
Ich weiss nicht, ob es Sinn macht diese Information den Sticky-OTA Theat zu spiegeln, denn hier gehen sie komplett unter.
Auf der anderen Seite interessiert es ja eh kaum jemanden..
Die TPI ist genau beschrieben:
Die Tätigkeiten werden per MassnahmenCode aufgerufen und laufen damit komplett automatisiert.
Abgerechnet werden dürfen 20ZEs
Mit in die Werkstattfahren, Tester anschliessen und Freischalten, Flashen und wieder herausfahren MUSS das in weniger als 30 Minuten geschafft sein, wenn nicht anderes hinzu kommt
Die TPI für 3.5.3 ist vlt. nicht korrekt.
das ist ehr ausgeschlossen zumal sayhelloto nach dem OTA Update die ABT SW 6091 erhalten hat:
Die Frage ist ehr, ob es ggf. ein Hardwareunterschied zwischen den ABTs gibt (also vergleichbar den 10" ABTs- beim ID), der mit unterschiedlichen SW beschrieben wird oder ob es im Nachgang eine Änderung im SWV der OTA gegeben hat, die die entsprechende Pause zwischen den Wellen erklären könnte.
Auch auffällig:
haben frühe Updater eine merklichen Performance-Unterschied bei der Bedienung , wird dies aktuell ehr relativiert.
Das ist durch den Unterschied der Funktionsweisen von ABT 6085 und ABT 6091 zu erklären
1751 steht drin, also zumindest für mein Verständnis nichts über neues und super spezielles von Cupra programmiertes für die armen Update-toten.
die SW3.5.3 ist nicht über die ICAS3 Software zu identifizieren.
Dafür musst die Software auf dem Inverter auslesen, diese unterscheidet sich zwischen SW3.5.2 und SW3.5.3
Hab gelesen, es gibt wohl ne Möglichkeit das Fzg durch n Hardreset in N zu bekommen und dann mit Ranghierhilfe zu arbeiten.
(..)
Mir wurde ja zunächst auch die 12V und dann sogar die HV Batterie (vom Abschleppmann) abgeklemmt - erfolglos.
Die Rollfähigkeit nach einem ab-/unterbrochenen Software-Update ist Hilfe eine Diagnosetesters und einer Online-Verbindung zu ODiS-Server wieder herstellbar.
Abklemmen der 12V Batterie bringt nicht, HV abklemmen schon überhaupt nicht.
Die Parkbremse muss gelöst werden, dass geht nur über die Ansteuerung aus ESP und eBKV.
Alternativ Rangierhilfe unter die hinteren Räder und schieben..
Möglicherweise gibt es einen weiteren Fix für das Lenkrad
(..)
Der Techniker beim nächsten Termin meinte dann, "dass der richtige Fix noch nicht eingespielt sei". Nun war das Heizverhalten die letzten Male noch besser.
Mit dem SW-Update auf SW 3.5.2 bekommt die Clima eine neue Software
Wenn man einen Ladeverlust von ca 8% beim AC Laden zugrunde legt komme ich auf eine Akkukapazität von 49,68KW
Immer die Akku-Temperatur bei solchen Messungen berücksichtigen.
Erwärmt sich der Akku wärend des Ladens nur unwesendlich und bleibt z.B. unter 10°C, gibt der Akku nicht seine voll Kapazität frei, bzw kann diese nicht vollständig nutzen. (reversibler Temperatureffekt). Entsprechend komme ich auch weniger gespeichert..
Möglich, dass so 1 .. 3% mehr Kapazität bei 20°C Akkutemperatur vorhanden sind.
Auf den ersten drei km an diesem Tag habe ich dann 5% Akku verbraucht. Kalt losgefahren, wie immer.
Also ein weitere Born mit SW3.2.1 und gleicher SoC Problematik...
Es ist halt nicht ausgeschlossen, dass die temperaturbedingte und reversible Kapazitätreduktion in dieser Phase den Kunden etwas ungünstig angezeigt wird, da er den gleichen Effekt, wie ein niedrigere SoC des Akkus hat.
Ich habe diese These schon einmal beschrieben, da sie auch berücksichtigt, dass es bei Erwärmung wieder mehr Kapazität zur verfügung steht und damit der SoC-Abfall deutlich verlangsamt wird.
Mir ist jetzt schon sehr oft aufgefallen das wenn ich bei den jetzigen Temperaturen ohne vorher den Innenraum zu heizen losfahre, der Akku dermaßen viel an Prozent verliert auf den ersten Kilometern, dass ich das einfach für unverhältnismäßig und erschreckend finde.
Ich bin an dem Thema dran..
Es scheint, als ob der Nutz-SoC, der in der ECU bestimmt wird, sich "verkalibriert".
Vergleicht man in einer solchen Situation Nutz-SoC und Real-SoC, sieht man, dass sich beides nicht mehr proportional zu einander verhält.
Rechnet man dann noch die entnommene Energie des Akkus aus der Integration aus BatterieStrom und Spannung, sieht man, dass der Nutz-SoC deutlich schneller sinkt, als die entnommene Energie es erwarten lässt. Interessanter Weise passt die Reduktion der nutzbaren Energie, dem die Batterie selber kommuniziert, zum berechneten Wert.
Fährt man länger nach einem schnellem Nutz-SoC Verlust, relativiert sich dieser wieder.
Also, hatte ich z.B. einen 8% SoC Verlust auf dem ersten Teil einer Strecke von 8km, habe ich auf den kommenden 36km nur noch 6% SoC verbraucht.
Auf die Gesamtstrecke von 44km passt der SoC Verlust von 14% wieder zu allen anderen Fahrten auf der gleichen Strecke zu vergleichbaren Wetterverhältnissen.
Auch passt die Energieentnahme auf dieser Strecke zu den 14% SoC Verlust der 58kWh Batterie.
Daher tippe ich derzeit auf eine "Verkalibierung" des Nutz-SoC in der ECU, die bei mir mit dem Update auf Sw3.2.1 eine neue Software bekommen hat.
Zuvor hatte ich das Problem nicht.
Dieses seltsame Verhalten tritt sporadisch bei mir auf, nicht dauerhaft..
Ich habe auch umgekehrte Fälle, bei denen sich der Nutz-SoC auf 7,5km garnicht geändert hat, während der Real-SoC um 1,15% verringerte,
Diese 1,15% Real-SoC Verringerung passte wieder zu den 1330Wh entnommenen Energie aus der Batterie auf dieser Strecke...
Mal sehen, wie ich das der Technik-Abteilung bei VW/Cupra erklärt bekomme, was sich das gerade komisch verhält...
