Analyses détaillées des données circulant sur le bus CAN pour les TM3 SR+ LFP55

[Jboll]

Le 02/07/2023 à 14:34, MrFurieux a dit :

A propos de 100%, pour info je tente en ce moment une expérience d'absence de recharge à 100% pendant plusieurs semaines pour voir. Message d'avertissement ? Augmentation du buffer bas ? Autre chose ?

V2023.20.4.1, pour mémoire.

Mais c'est pas une NCA que tu as ?

[MrFurieux]

Le 02/07/2023 à 14:43, Jboll a dit :

Mais c'est pas une NCA que tu as ?

J'en ai eu une, mais maintenant LFP(60)

[Jboll]

De mon côté j'ai trouvé un truc bizzare en regardant de plus prés les oscillations par palier vu a chaque valeur dont l'unité est le kWh :

 

Par exemple le nominal remaining lors d'une charge :

 

Comme déjà dit précédemment, les valeurs de kWh transmises sur le bus CAN ont une partie décimale discrètes, à savoir :

 

xxx.00 kWh

xxx.12 kWh

xxx.24 kWh qui oscille avec xxx.26 kWh

xxx.38 kWh

xxx.50 kWh

xxx.62 kWh

xxx.74 kWh qui oscille avec xxx.76 kWh

xxx.88 kWh

 

Il n'y a pas d'autres valeurs possible

 

Concernant la valeur de l'oscillation de 0.02 kWh, c'est tout simplement la précision du signal, il n'est pas possible de faire mieux

Autrement dit, 1 bit correspond à 0.02 kWh

BO_ 850 ID352BMS_energyStatus: 8 VehicleBus
 SG_ BMS_energyStatusMultiplexer M : 0|2@1+ (1,0) [0|3] "" VehicleBus
 SG_ BMS_nominalFullPackEnergy m0 : 16|16@1+ (0.02,0) [0|1310.7] "kWh" VehicleBus
 SG_ BMS_nominalEnergyRemaining m0 : 32|16@1+ (0.02,0) [0|1310.7] "kWh" VehicleBus
 SG_ BMS_idealEnergyRemaining m0 : 48|16@1+ (0.02,0) [0|1310.7] "kWh" VehicleBus
 SG_ BMS_fullChargeComplete m1 : 15|1@1+ (1,0) [0|1] "" VehicleBus
 SG_ BMS_energyBuffer m1 : 16|16@1+ (0.01,0) [0|655.35] "kWh" VehicleBus
 SG_ BMS_expectedEnergyRemaining m1 : 32|16@1+ (0.02,0) [0|1310.7] "kWh" VehicleBus
 SG_ BMS_energyToChargeComplete m1 : 48|16@1+ (0.02,0) [0|1310.7] "kWh" VehicleBus

 

Pour les paliers, on vient de voir que la précision du signal c'est 0.02 kWh, il est largement possible de transmettre toutes les valeurs qu'on veux, avec un pas de 0.02 kWh. Pourtant les paliers sont espacés de 0.12 kWh voir 0.14 kWh

 

On peux se dire : "oui, mais avant ce message n'était pas découpé en deux, et il fallait tout faire tenir dans un seul message. Donc la précision des paliers venait peut-être de là : maintenant il y a deux messages mais ça veut pas dire que Tesla n'aurait pas gardé la précédente précision pour ce remaining"

 

Alors, voici le message que l'on avait avant :

//BO_ 850 ID352BMS_energyStatus: 8 VehicleBus
// SG_ BMS_energyBuffer : 55|8@1+ (0.1,0) [0|25.4] "KWh"  Receiver
// SG_ BMS_energyToChargeComplete : 44|11@1+ (0.1,0) [0|204.6] "KWh"  Receiver
// SG_ BMS_expectedEnergyRemaining : 22|11@1+ (0.1,0) [0|204.6] "KWh"  Receiver
// SG_ BMS_fullChargeComplete : 63|1@1+ (1,0) [0|1] ""  Receiver
// SG_ BMS_idealEnergyRemaining : 33|11@1+ (0.1,0) [0|204.6] "KWh"  Receiver
// SG_ BMS_nominalEnergyRemaining : 11|11@1+ (0.1,0) [0|204.6] "KWh"  Receiver
// SG_ BMS_nominalFullPackEnergy : 0|11@1+ (0.1,0) [0|204.6] "KWh"  Receiver

 Le signal avait avant une précision de 0.1 kWh, il n'y avait donc qu'un seul chiffre significatif après la virgule

Donc ça vient pas de là...

 

Sur SMT, c'est précis à 0.1 prés :

Par exemple :

 

 

 

Petit truc rigolo, ça ne marche pas pour le buffer bas !

puisse que j'ai déjà eu 2.31 ! 

 

Ce qui est assez étonnant, et voici toutes les valeurs que j'ai noté pour ce buffer bas :

 

il peut évoluer toutes les 0.01 kWh, et est donc limité par la précision du message qui transiste sur le bus :

BO_ 850 ID352BMS_energyStatus: 8 VehicleBus
 SG_ BMS_energyStatusMultiplexer M : 0|2@1+ (1,0) [0|3] "" VehicleBus
 SG_ BMS_nominalFullPackEnergy m0 : 16|16@1+ (0.02,0) [0|1310.7] "kWh" VehicleBus
 SG_ BMS_nominalEnergyRemaining m0 : 32|16@1+ (0.02,0) [0|1310.7] "kWh" VehicleBus
 SG_ BMS_idealEnergyRemaining m0 : 48|16@1+ (0.02,0) [0|1310.7] "kWh" VehicleBus
 SG_ BMS_fullChargeComplete m1 : 15|1@1+ (1,0) [0|1] "" VehicleBus
 SG_ BMS_energyBuffer m1 : 16|16@1+ (0.01,0) [0|655.35] "kWh" VehicleBus
 SG_ BMS_expectedEnergyRemaining m1 : 32|16@1+ (0.02,0) [0|1310.7] "kWh" VehicleBus
 SG_ BMS_energyToChargeComplete m1 : 48|16@1+ (0.02,0) [0|1310.7] "kWh" VehicleBus

 

Alors ? d'où vient ces valeurs bizzare pour le remaining :

xxx.00 kWh

xxx.12 kWh

xxx.24 kWh qui oscille avec xxx.26 kWh

xxx.38 kWh

xxx.50 kWh

xxx.62 kWh

xxx.74 kWh qui oscille avec xxx.76 kWh

xxx.88 kWh

 

Et bien je pense que ça vient de l'encodage des valeurs avec un scale de 0.02, il faudrait que je regarde un autre signal avec un même scale, comme par exemple :

BO_ 594 ID252BMS_powerAvailable: 8 VehicleBus
 SG_ BMS_hvacPowerBudget : 50|10@1+ (0.02,0) [0|20.46] "kW"  Receiver
 SG_ BMS_maxDischargePower : 16|16@1+ (0.013,0) [0|655.35] "kW"  Receiver
 SG_ BMS_maxRegenPower : 0|16@1+ (0.01,0) [0|655.35] "kW"  Receiver
 SG_ BMS_maxStationaryHeatPower : 32|10@1+ (0.01,0) [0|10.23] "kW"  Receiver
 SG_ BMS_notEnoughPowerForHeatPump : 42|1@1+ (1,0) [0|1] ""  Receiver
 SG_ BMS_powerLimitsState : 48|1@1+ (1,0) [0|1] ""  Receiver

 

Mais ce sera pour une autre fois

 

 

 

[Jboll]

Le 02/07/2023 à 15:09, MrFurieux a dit :

J'en ai eu une, mais maintenant LFP(60)

Ah la bonne nouvelle 😁, justement on cherchait une âme charitable pour démonter son pack 60 pour voir comment sont agencées les cellules 😉

 

D’ailleurs j’en profite, est ce que tu as une dégradation moyenne de 1km/mois ou 0,7 Km/mois ?

[MrFurieux]

Le 02/07/2023 à 15:29, Jboll a dit :

Comme déjà dit précédemment, les valeurs de kWh transmises sur le bus CAN ont une partie décimale discrètes, à savoir :

 

xxx.00 kWh

xxx.12 kWh

xxx.24 kWh qui oscille avec xxx.26 kWh

xxx.38 kWh

xxx.50 kWh

xxx.62 kWh

xxx.74 kWh qui oscille avec xxx.76 kWh

xxx.88 kWh

On dirait un pas de 0,125 ? Ça peut venir d'une multiplication oui 

 

Le 02/07/2023 à 16:17, Jboll a dit :

D’ailleurs j’en profite, est ce que tu as une dégradation moyenne de 1km/mois ou 0,7 Km/mois ?

De l'ordre de 1 km/mois comme tout le monde - à ma connaissance c'est pareil pour les 55 ou les 60 jusqu'ici.

J'ai pas le souvenir d'avoir vu 0,7/mois, le minimum c'était des 55 sur les 12 derniers mois qui étaient plutôt vers -0,8/-0,9

[Jboll]

Le 02/07/2023 à 20:48, MrFurieux a dit :

On dirait un pas de 0,125 ? Ça peut venir d'une multiplication oui

Oui mais 0,125 ça demande 3 nombres après la vigile, et le message n’en autorise que deux. 
 

il y a peut être un genre d’algorithme pour faire passer une valeur sans perte. Où il réajuste a chaque envoie la valeur en fonction de ce qui a déjà été transmis

 

 j’ai essayé de regarder si les oscillations ressemble a quelque chose et a part du bruit ou de l’aléatoire je vois pas. Mais aucune raison que ce soit l’un ou l’autre. 

ce qui est étonnant aussi, c’est qu’il n’y a que deux valeurs qui oscilles, comme si les autres tombaient juste. Après tout, 0,12 devrait osciller avec 0,13 si le pas c’est 0,125 

mais c’est pas le cas

 

il y a un bout de physique quantique là dedans : si on comprend la physique quantique c’est qu’on la comprend pas 🙃🙂

 

 

[Jboll]

Quand on utilise des pas, c’est parce que souvent ça cache soit un manque de précision (mais ça semble pas être le cas ici: le message permet davantage) soit un hysteresis, histoire d’éviter que ça oscille à l’affichage.

Ici 0,12kWh ça représente 1km

alors cette valeur évite que les Km tremblent à l’affichage, qui aurait sans doute lieu avec un simple arrondi

 

mais qui dit hysteresis dit deux valeurs, une montante et une descendante

 

Et donc les deux quart de kWh n’en auraient pas… bizarre… 

[MrFurieux]

Le 02/07/2023 à 21:32, Jboll a dit :

Oui mais 0,125 ça demande 3 nombres après la vigile, et le message n’en autorise que deux. 
 

il y a peut être un genre d’algorithme pour faire passer une valeur sans perte. Où il réajuste a chaque envoie la valeur en fonction de ce qui a déjà été transmis

 

 j’ai essayé de regarder si les oscillations ressemble a quelque chose et a part du bruit ou de l’aléatoire je vois pas. Mais aucune raison que ce soit l’un ou l’autre. 

ce qui est étonnant aussi, c’est qu’il n’y a que deux valeurs qui oscilles, comme si les autres tombaient juste. Après tout, 0,12 devrait osciller avec 0,13 si le pas c’est 0,125 

mais c’est pas le cas

ça peut être la val avant le transfert qui a 3 chiffres après la virgule en décimal - et ça peut être du binaire plutôt que du décimal, et dans ce ças c'est différent: 0,125 * 8 = 1.

Effectivement il y a forcément une imprécision de mesure et il pourrait y avoir une hystérésis pour éviter que ça bloblotte. Si l'oscillation 0,24/0,26 et 0,74/0,76 est centrée sur 0,25 / 0,75, tandis que pour les autres valeurs on oscille autour de X,X5 décimal, ça pourrait donner ce que tu relèves.

Que la précision du message soit supérieure à celle de la mesure, c'est normal mais pas suffisant.

En tout cas ça donne l'impression que l'imprécision de mesure est de plus de 0,1 kWh, et comme c'est en fait une estimation, ça parait pas trop surprenant.

[tben]

Le 02/07/2023 à 21:54, Jboll a dit :

Quand on utilise des pas, c’est parce que souvent ça cache soit un manque de précision (mais ça semble pas être le cas ici: le message permet davantage) soit un hysteresis, histoire d’éviter que ça oscille à l’affichage.

Ici 0,12kWh ça représente 1km

alors cette valeur évite que les Km tremblent à l’affichage, qui aurait sans doute lieu avec un simple arrondi

 

mais qui dit hysteresis dit deux valeurs, une montante et une descendante

 

Et donc les deux quart de kWh n’en auraient pas… bizarre… 

Tu remarqueras qu'il y a bien une hysteresis entre la montée ou la descente d'un pas. Il me semble que je n'ai pas le même nombre de Wh (calculé par intégration) entre deux sots si je monte, puis monte, puis descend, puis monte. Je n'ai pas suffisamment regardé, car pour l'instant j'essaie de comprendre quand cela ne fait que monter ou descendre.

[Jboll]

Le 02/07/2023 à 15:29, Jboll a dit :

je pense que ça vient de l'encodage des valeurs avec un scale de 0.02, il faudrait que je regarde un autre signal avec un même scale, comme par exemple :

BO_ 594 ID252BMS_powerAvailable: 8 VehicleBus
 SG_ BMS_hvacPowerBudget : 50|10@1+ (0.02,0) [0|20.46] "kW"  Receiver
 SG_ BMS_maxDischargePower : 16|16@1+ (0.013,0) [0|655.35] "kW"  Receiver
 SG_ BMS_maxRegenPower : 0|16@1+ (0.01,0) [0|655.35] "kW"  Receiver
 SG_ BMS_maxStationaryHeatPower : 32|10@1+ (0.01,0) [0|10.23] "kW"  Receiver
 SG_ BMS_notEnoughPowerForHeatPump : 42|1@1+ (1,0) [0|1] ""  Receiver
 SG_ BMS_powerLimitsState : 48|1@1+ (1,0) [0|1] ""  Receiver

 

Mais ce sera pour une autre fois

 

Pour suite..

 

Je n'avais pas de donnée pour le message, ci-dessous, j'en ai cherché un autre avec un scale de 0.02, et j'ai choisi le message suivant:

 

BO_ 786 ID312BMSthermal: 8 VehicleBus
 SG_ BMSdissipation312 : 0|10@1+ (0.02,0) [0|20] "kW"  Receiver
 SG_ BMSflowRequest312 : 10|7@1+ (0.3,0) [0|30] "LPM"  Receiver
 SG_ BMSinletActiveCoolTarget312 : 17|9@1+ (0.25,-25) [-25|100] "C"  Receiver
 SG_ BMSinletActiveHeatTarget312 : 35|9@1+ (0.25,-25) [-25|100] "C"  Receiver
 SG_ BMSinletPassiveTarget312 : 26|9@1+ (0.25,-25) [-25|100] "C"  Receiver
 SG_ BMSnoFlowRequest312 : 63|1@1+ (1,0) [0|1] ""  Receiver
 SG_ BMSpcsNoFlowRequest312 : 62|1@1+ (1,0) [0|1] ""  Receiver
 SG_ BMSmaxPackTemperature : 53|9@1+ (0.25,-25) [-25|100] "C"  Receiver
 SG_ BMSminPackTemperature : 44|9@1+ (0.25,-25) [-25|100] "C"  Receiver

 

Et j'ai regardé les valeurs prise lors d'un trajet, pour voir si ça oscille aux même palier :

Ps : il s'agit d'un trajet puis d'une super charge en plein milieu puis du trajet retour

 

Alors, déjà, il n'y a pas de palier, l'incrément est bien 0.02 (précision du bus)

0.02

0.04

0.08

0.1

0.12

0.14

0.16

0.18

 

Donc pas facile de voir si ça oscille dans un palier, vu qu'il n'y a pas de palier...

 

Je me suis dit que les paliers pouvait venir uniquement des kWh, alors j'ai regardé un nouveau message, même trajet :

 

BO_ 130 ID082UI_tripPlanning: 8 VehicleBus
 SG_ UI_energyAtDestination : 48|16@1- (0.01,0) [-327.67|327.67] "kWh"  Receiver
 SG_ UI_hindsightEnergy : 32|16@1- (0.01,0) [-327.67|327.67] "kWh"  Receiver
 SG_ UI_navToSupercharger : 1|1@1+ (1,0) [0|1] ""  Receiver
 SG_ UI_predictedEnergy : 16|16@1- (0.01,0) [-327.67|327.67] "kWh"  Receiver
 SG_ UI_requestActiveBatteryHeating : 2|1@1+ (1,0) [0|1] ""  Receiver
 SG_ UI_tripPlanningActive : 0|1@1+ (1,0) [0|1] ""  Receiver

 

C'est le message de la planification du trajet, et le suivie de l'énergie

 

Et le graphique associé :

J'ai bien une valeur xx.26 mais n'oscille pas

 

Et qui peut prendre toutes les valeurs a 0.01 prés, 

ici xxx.93 n'est pas remarquable :

Ou encore xx.51 

 

 

Donc :

- Les paliers ne pas forcément présent pour des kWh : c'est pas lié à l'unité

- Les paliers ne pas forcément présent pour une échelle de 0.02

 

Bref, pour l'instant je ne les vois que pour le remaining & le nfp

 

Ces paliers sont donc liés, ni à l'unité, ni à la précision du bus, mais bien lié à la nature de ces informations

Et comme le NFP prend la valeur du remaining en fin de charge, alors c'est plutôt lié uniquement au remaining qui marche par palier d'environ 0.125kWh ou ~ 1Km 

 

Il y a quelques posts, je pensais que c'était dû à l'affichage, pour ne pas que ça oscille à l'affichage, mais avec un peu de recul, je me dit que si c'est juste un problème d'affichage, ça aurait pû être réglé au niveau affichage, au plus proche de l'écran, par exemple quand la valeur est arrondi en km. 

Aucune raison de prévoir des paliers sur un bus interne pour cause de l'affichage

 

Alors j'ai une autre hypothèse, c'est que le remaining dépend d'une autre valeur, de quelque chose d'autre, et qui lui aurait une précision moins importante. En tout logique, le remaining à l'instant n dépend du remaining à l'instant n-1 de la tension, de l'intensité et du temps. et vu la précision qu'on les trois valeurs ça m'étonnerait que le problème de précision viennent de là.

 

Pour les autres chimies, le remaining dépends de la valeur en % (voir schéma quelques posts avant) 

Du coup je me demande si c'est pas aussi le cas sur nos LFP

Pour savoir si c'est le remaining qui influence le % ou l'inverse, il faudrait regarder qui bouge en premier

 

Eh bien c'est parti…

 

Voici le message du SOC en % 

BO_ 658 ID292BMS_SOC: 8 VehicleBus
 SG_ BattBeginningOfLifeEnergy292 : 40|10@1+ (0.1,0) [0|102.3] "kWh"  Receiver
 SG_ SOCmax292 : 20|10@1+ (0.1,0) [0|102.3] "%"  Receiver
 SG_ SOCave292 : 30|10@1+ (0.1,0) [0|102.3] "%"  Receiver
 SG_ SOCUI292 : 10|10@1+ (0.1,0) [0|102.3] "%"  Receiver
 SG_ SOCmin292 : 0|10@1+ (0.1,0) [0|102.3] "%"  Receiver
 SG_ BMS_battTempPct : 50|8@1+ (0.4,0) [0|100] "%"  Receiver

En bleu en haut le remaining, et en bas en bleu aussi (dsl) la moyenne des SOC en %

 

Ici le % arrive bien avant le remaining

 

Idem lors du début de ma charge, c'est bien le % qui augmente en premier, et après le remaining:

a la ligne verticale rouge, le remaining n'a toujours pas bougé alors que le % augmente depuis 10 secondes

 

Pareil en fin de charge, le % est encore en avance :

(ps : le remaining oscille derrière car on est sur le palier xx.74 <-> xx.76)

 

Pareil en roulant/déchargeant :

Bref le remaining semble toujours avoir un temps de retard sur le % d'environ 10-15 secondes

 

Ce qui est assez fou  

 

Alors du coup, comme est calculé ce % si c'est pas depuis le remaining ?

 

Déjà il y a plusieurs % dans le message, un min, un max, un ave (je ne sais pas ce que àa veux dire), et un pour l'interface utilisateur :

Je m'attendais à voir qu'un seul %, pourquoi en avoir autant  

Après, je m'attendais à ce que "ave" soit la moyenne et donc soit pile au milieu du min et du max, ce qui n'est pas le cas : plus proche du max. Donc c'est pas la moyenne

Ils ne bougent pas à la même précision, celui de l'UI en jaune est très grossier, les 3autres sont beaucoup plus précis

ET il bougent pas au même rythme : certains sont en avance sur d'autre

 

 

C'est d'abord le ave (1) puis le UI et le Max (2) puis le min (3)

 

Note : Dans l'exercice avec le SOC en % vs le SOC en kWh (remining) j'ai choisi le ave, celui qui bouge en premier

 

Et lors de la décharge c'est qui le premier ?

Eh bien c'est le min (1) puis le max(2) puis le ave (3) et enfin l'interface graphique ui (4)

 

Du coup c'est pas le même ordre 0_o

 

Lors du début de la charge :

c'est d'abord le max (1) puis le min (2) puis le ave(3) puis l'ui (4)

 

Ok.. c'est pas le même ordre mais il semble avoir une logique quand même : quand on décharge on repousse le min vers le bas et c'est lui qui doit faire descendre les autres j'imagine (le même mécanisme lors d'une fin de charge ou le remaining attire le NFP)

Et en charge c'est l'inverse : c'est le max qui se fait pousser, et tire avec lui, quelques secondes plus tard, le min

ça ressemble donc a une fenêtre coulissante où dès qu'on touche un bord on déplace la fenêtre.

En d'autre termes : c'est un hystérésis que l'on voit devant nous : un hystérésis de % !

 

(Soit dit en passant, si le % était calculé depuis le remaining, il n'y aurait pas besoin d'avoir autant de type de % différents  )

 

Et donc si le % a un hystérésis, alors le remaining va évaluer en palier  

ça semble logique maintenant

 

Oui mais alors ? comment est calculé le % qui fait bouger cette fenêtre ? et comment il s'appelle ?

Pour son nom, je ne sais pas, pour l'exercice je vais juste l'appeler "% mesuré"

 

Et puis si un % de quoi ? un % d'une valeur en kWh ? ben non sinon on retombe sur le problème d'avant : les kWh sont calculé après le %

Donc c'est un % de quoi ? c'est quoi l'unité ?

Ben il ne reste que la tension (j'en connais un qui commence a grincer des dents  )

 

Prochaine étape : calculer le % depuis une tension et une intensité mais pas en faisant une intégration

 

Pour chaque valeur d'intensité la courbe de tension en fonction du SOC est différent, ça voudrait dire que le BMS stocke en interne un modèle qui permet à partir du couple (tension, intensité) de sortir -> un % de SOC

 

Et c'est là que les autres valeurs du BMS sont intéressante, je rappelle le message : 

BO_ 850 ID352BMS_energyStatus: 8 VehicleBus
 SG_ BMS_energyStatusMultiplexer M : 0|2@1+ (1,0) [0|3] "" VehicleBus
 SG_ BMS_nominalFullPackEnergy m0 : 16|16@1+ (0.02,0) [0|1310.7] "kWh" VehicleBus
 SG_ BMS_nominalEnergyRemaining m0 : 32|16@1+ (0.02,0) [0|1310.7] "kWh" VehicleBus
 SG_ BMS_idealEnergyRemaining m0 : 48|16@1+ (0.02,0) [0|1310.7] "kWh" VehicleBus
 SG_ BMS_fullChargeComplete m1 : 15|1@1+ (1,0) [0|1] "" VehicleBus
 SG_ BMS_energyBuffer m1 : 16|16@1+ (0.01,0) [0|655.35] "kWh" VehicleBus
 SG_ BMS_expectedEnergyRemaining m1 : 32|16@1+ (0.02,0) [0|1310.7] "kWh" VehicleBus
 SG_ BMS_energyToChargeComplete m1 : 48|16@1+ (0.02,0) [0|1310.7] "kWh" VehicleBus

Il y a trois valeurs, ici en rouge, qui sont toutes des remaining, pourquoi plusieurs ? 

A noter que les autres valeurs n'ont pas cette particularité : il n'y a que un seul NFP, que un seul buffer bas, qu'un seul energieToCharge ! 

 

Pourquoi le remaining a t-il droit a ce traitement de faveur ? en quoi le remaining est-il différent des autres ?

 

Et bien je pense que c'est justement pour diminuer l'erreur de son modèle en faisant de l'apprentissage continue, si les valeurs divergent, il peux réajuster : c'est à dire qu'il fait les deux, ils comptent les coulombs pour l'un, il utilise le % pour l'autre. et si c'est pas correcte, il réajuste son modèle.

 

Au fait, parmi ces trois remaining, on est d'accord que les 3 évoluent bien après le % hein  

Voyons voir

Au début du trajet, c'est d'abord le ave en % qui va venir avant le nominal remaining (1) puis le ideal/expected (2)

Donc : ok !

 

Pareil en début de charge :

Donc : ok !

 

Et en fin de charge ...

Malheurs ! le nominal remaining (1) arrive AVANT le % (2)

 

J'ai eu un gros doute à ce moment là, mais je me suis rappelé que le % en fin de charge, ça veut rien dire : et qu'il était 2 fois plus long que les autres % a passer, il doit avoir une particularité à la valeur 100, sans doute pour afficher à l'utilisateur 100% quand la charge est terminée, alors qu'une mise à jour précédente faisait d'abord passer à 100% puis arrêter quelques temps après la charge

Donc je pense que c'est juste le BMS qui décale l'envoie de la valeur 100, mais qu'elle vaut bien 100 avant qu'il ne l'envoie 

 

 

Et pour le début de la décharge c'est bien le % en premier :

Donc : ok !

 

 

Bref... 

Pour le moment j'en suis ici dans ma réflexion :

(tension + intensité) -> SOC % -> réajustement des min/max SOC en % -> palier des remaining en kWh -> Mi -> Km

 

 

 

 

[MrFurieux]

Ouf ! Impressionnant pavé d'exploration. Je ne comprends pas toutes les suppositions, mais sur la question de base "pourquoi des variations grossières sur le remaining", j'ai une proposition: contrairement aux mesures tension / intensité / temps (à partir desquelles le BMS peut calculer précisément une puissance ou énergie électrique par U.I ou U.I.t), le remaining ou % est une estimation faite sans pouvoir mesurer les pertes - pertes par effet joule et par le rendement "chimique" < 100% à la charge / décharge en fct de la puissance.

A 100% il reste l'incertitude du SOH mais sinon c'est un point de référence qui élimine les autres incertitudes.

[tben]

Le 04/07/2023 à 17:00, Jboll a dit :

Pour suite..

Bravo, très belle étude.

[Hybridébridé]

Le 28/06/2023 à 08:16, Jboll a dit :

effectivement CATL fabrique des batteries de 173Ah également

 

 ça pourrait être celle là pour les LFP 60 (model 3 + model y)

 

 

Les caractéristiques de la LFP 55 :

 

ND-3.2V 161AH

Tension nominale: 3.2V
Capacité standard: 161A
Taille: 280*82*62mm (ne comprend pas les goujons)
Poids: 3.1 ± 0.3kg
Tension de charge: 3.65V
Tension de coupure de décharge: 2.0V
Résistance interne AC: ≤ 0.5mΩ
Courant de charge standard: 0.5C
Courant de charge max.: 1C
Courant de décharge standard: 0.5C
Courant de décharge continu max: 1C
Température de fonctionnement
Charge: 0 ℃ ~ 45 ℃
Décharge: -20 ℃ ~ 60 ℃

 

et pour la LFP 60 :

 

ND-3.2V 173AH

Tension nominale: 3.2V
Capacité standard: 173Ah
Taille: 174*40*207mm (n'inclut pas les goujons)
Poids: ≤ 3.2kg
Tension de charge: 3.65V
Tension de coupure de décharge: 2.0V
Résistance interne AC: ≤ 0.3mΩ
Courant de charge standard: 0.5C
Courant de charge max.: 1C
Courant de décharge standard: 0.5C
Courant de décharge continu max: 1C
Courant de décharge Max Pules: 3C
Température de fonctionnement
Charge: 0 ℃ ~ 50 ℃
Décharge: -20 ℃ ~ 60 ℃

 

 

 

 

https://m.fr.aliexpress.com/item/1005002998124905.html

Merci pour la recherche. Sauf que 108 cellules de 173 Ah, ça le fait pas :

• En tension : voir les captures de Bjorn dans mon post joint plus haut. Une est certes en toute fin de recharge recharge, mais c'est justement la LFP 55 kWh ce qui va pas dans le bon sens. On trouve d'ailleurs 3,44 V par cellule pour la 55 kWh, mais 3,58 V avec 108 cellules pour la 60 kWh qui est en début de décharge. Ca ne colle pas.
• En capacité : du fait des 62 kWh en décharge récupérés par l'EPA
• En position : il faudrait vérifier combien de cellules de 173 Ah on peut mettre en position horizontale dans les dimensions d'un pack de model 3, mais pour des raisons industrielles, ce changement est difficilement imaginable : complexification des collecteurs, impossibilité de souder en un passage par le dessus, revue complète du refroidissement du pack, etc...

 

Celà étant, on ne trouve pas d'info sur le CATL CTP 2.0 : seul un démontage pourrait nous révéler la vérité mais malheureusement, on n'en trouve pas en Open Source.

[Jboll]

Le 05/07/2023 à 22:19, Hybridébridé a dit :

En tension : voir les captures de Bjorn dans mon post joint plus haut. Une est certes en toute fin de recharge recharge, mais c'est justement la LFP 55 kWh ce qui va pas dans le bon sens. On trouve d'ailleurs 3,44 V par cellule pour la 55 kWh, mais 3,58 V avec 108 cellules pour la 60 kWh qui est en début de décharge. Ca ne colle pas

Pas sûr  de bien comprendre ce qui colle pas, c’est quoi ce qui gênant dans ces tensions?

(ps: c’est peut être hors sujet mais j’avais lu qu’avant nos LFP terminaient leur charge à une tension inférieur, 3,6v de mémoire, et c’est lors d’une mise à jour que cette tension de fin de charge a été repoussée à 3,8v, je sais pas si c’est lié à ce que tu dis?)

 

Le 05/07/2023 à 22:19, Hybridébridé a dit :

En capacité : du fait des 62 kWh en décharge récupérés par l'EPA

Le test EPA a récupéré 62kWh dans cette batterie c’est ça?

 

 

Le 05/07/2023 à 22:19, Hybridébridé a dit :

En position : il faudrait vérifier combien de cellules de 173 Ah on peut mettre en position horizontale dans les dimensions d'un pack de model 3, mais pour des raisons industrielles, ce changement est difficilement imaginable : complexification des collecteurs, impossibilité de souder en un passage par le dessus, revue complète du refroidissement du pack, etc...

Oui, Comme ça par exemple:

 

les cellules semblent allongées ici :


 

Pour le système de refroidissement… comment dire… c’est plutôt un système de chauffage si j’ai bien compris

 

le fait de les empiler ça les tient bien au chaud 🙄 nickel 🥴

[Hybridébridé]

@Jboll : trop fort ! grâce à toi, on sait tout sur le CTP 2.0, donc 108 cellules allongées.

 

Donc effectivement, les tensions sont plus hautes à 100%.

 

Et oui, 62 kWh, c'est ce qui a été mesuré en décharge par l'EPA. Ca colle avec une tension moyenne supérieure de 0,15 V au pack 55 kWh.

 

Conception totalement différente du pack 55 kWh. Les comparaisons deviennent difficiles.

[MrFurieux]

Le 06/07/2023 à 00:56, Jboll a dit :

les cellules semblent allongées ici :
 

Pour le système de refroidissement… comment dire… c’est plutôt un système de chauffage si j’ai bien compris

 

le fait de les empiler ça les tient bien au chaud 🙄 nickel 🥴

Comme @Hybridébridé j'étais sceptique sur un changement de forme des cellules entre les 55 et 60, mais oui il semble bien que ce soit le cas, les 173 font 4 cm d'épaisseur, donc empilement possible. Soit le nouveau facteur de forme les a obligé à modifier l'agencement, soit au contraire ils ont voulu une nouvelle forme pour optimiser l'agencement. Tu as la source ?

NB je crois que CATL chauffe les cellules par un courant interne et pas par le liquide, ils ont un genre de brevet pour cette technique.

 

Le 06/07/2023 à 10:47, Hybridébridé a dit :

 

Et oui, 62 kWh, c'est ce qui a été mesuré en décharge par l'EPA. Ca colle avec une tension moyenne supérieure de 0,15 V au pack 55 kWh.

Les courbes de tension dépendent essentiellement de la chimie, les cellules 173 ou 161 n'ont pas 0,15 V de différence sur l'ensemble de la courbe. Les 62 kWh EPA c'est un pack hors norme utilisé pour le test, à la livraison c'est entre 60 et 61 en général.

[Jboll]

Le 06/07/2023 à 12:35, MrFurieux a dit :

Tu as la source ?

https://www.zhihu.com/question/520430155?utm_id=0

 

https://www.batterydesign.net/mg-rubiks-cube-battery/

 

 

 

[Jboll]

Le 06/07/2023 à 12:35, MrFurieux a dit :

NB je crois que CATL chauffe les cellules par un courant interne et pas par le liquide, ils ont un genre de brevet pour cette technique

Sur le schéma, on croirait lire “composants de refroidissement verticaux”

 

[MrFurieux]

Le 06/07/2023 à 13:35, Jboll a dit :

https://www.zhihu.com/question/520430155?utm_id=0

 

https://www.batterydesign.net/mg-rubiks-cube-battery/

ok merci

 

Le 06/07/2023 à 13:40, Jboll a dit :

Sur le schéma, on croirait lire “composants de refroidissement verticaux”

Oui mais NB que c'est pas un pack Tesla, et que le refroidissement est liquide de toute façon - pour le chauffage interne je faisais référence à ça (dernière page).

Pour le pack MG le refroidissement passe entre les rangées de cellules, c'est ce qu'ils veulent dire par "Using both sides of the coolant plate halves the are of coolant plates required compared to having all of the cells arranged vertically". S'ils ont fait la même chose sur le pack Tesla ça veut peut-être dire qu'ils n'ont plus les 4 modules séparés mais seulement 3 ?

 

[Hybridébridé]

@Jboll, @MrFurieux : J'essaye de déplacer la discussion sur l'architecture du pack 60 kWh dans le fil ci-dessous bien plus adapté, d'autant plus qu'il intéresse aussi les model Y propulsion ; il me semble également qu'en en discutant ici, on est complètement à l'ouest par rapport à l'objet initial du fil créé par @tben, qui est également limité pour mémoire au pack 55 kWh :

 

De cette façon, les lecteurs du forum retrouveront mieux leurs petits. Merci.

[tben]

Le 06/07/2023 à 10:47, Hybridébridé a dit :

Conception totalement différente du pack 55 kWh. Les comparaisons deviennent difficiles.

Finalement j'avais eu la bonne intuition, et j'avais bien choisi le titre de cette discussion : LFP55.

Mais ceux qui ont d'autres batteries devraient plutôt ouvrir une nouvelle discussion, et nous ferions des liens entre elles quand l'une s'inspirera de l'autre. Sinon, cela va vite devenir incompréhensible. Déjà que c'est pas simple à comprendre

[Jboll]

Le 04/07/2023 à 17:00, Jboll a dit :

Bref... 

Pour le moment j'en suis ici dans ma réflexion :

(tension + intensité) -> SOC % -> réajustement des min/max SOC en % -> palier des remaining en kWh -> Mi -> Km

Bon, j'ai trouvé un truc sympa !!!

(mais un peu déçu de ma découverte d'aujourd'hui qui remet en cause ce que j'ai vu la dernière fois)

 

J'étais parti du principe que les paliers du remaining venait pas du fait d'arrondir les km à l'affichage, mais parce qu'il provenaient des % qui avait un hytérésis

 

Mais j'ai regardé avec plus d'attention un autre message contenant le total des kWh chargé et déchargé de la voiture, à savoir :

 

BO_ 978 ID3D2TotalChargeDischarge: 8 VehicleBus
 SG_ TotalDischargeKWh3D2 : 0|32@1+ (0.001,0) [0|4294970] "kWh"  Receiver
 SG_ TotalChargeKWh3D2 : 32|32@1+ (0.001,0) [0|4294970] "kWh"  Receiver

Je m'attendais à voir également des paliers. Et bien... non... pas du tout ! et en plus c'est précis à 0.001 prés ! soit au Wh prés !

 

Et effectivement, ça a l'air trés précis. J'ai tracé ci-dessous une charge, avec en bleu clair le remaining et ses paliers

Et en bleu foncé le totalCharge, et on vois bien que le total charge est beaucoup précis, et qu'il n'oscille pas a certains paliers, comme le remaining le fait 

 

Je pense que ce message est un très bon candidat pour tester la formule d'intégration UI(t)

Car précis au Wh prés !

 

Déjà, faisons un test pour voir si le remaining monte aussi vite que le TotalCharge  sur deux paliers, est-ce qu'on tombe sur la même valeur ?

 

1er point :

 

 

2ieme point

 

Les comptes maintenant :

- le remaining a augmenté de :51.62 - 51.38, c'est à dire 0.24 kWh

- le total charge a augmenté de 8027.569 - 8027.295, c'est à dire 0.27 kWh

- le total discharge n'a pas bougé (on est en charge sur un SUC ici)

 

 

Bon c'est pas vraiment probant, le total charge semble plus généreux, mais 2 paliers c'est trop peu pour conclure -> on va tester sur une charge beaucoup plus grande pour voir :

 

 

1er point

 

2iem

 

Les comptes maintenant :

- le remaining a augmenté de :51.5 - 39.24, c'est à dire 13.26 kWh

- le total charge a augmenté de 8027.535 - 8014.672, c'est à dire 12.863 kWh

- le total discharge n'a pas bougé (on est en charge sur un SUC ici)

 

 

Bon, ben il y a tout de même 0.397 kWh qui sont pas comptabilisé dans le remaining 

 

soit pile 3%

 

C'est marrant non ? de tomber pile sur une valeur...

ça l'air d'être une constante, sans doute mise là par Tesla ou CATL

Autrement dit, le remaining compte 3% de moins que le totalCharge

Autrement dit la voiture a bien détecté tout les kWh, mais 3% ne sont pas mis dans le compteur de remaining !

 

ça c'est une sacré découverte ! parce que c'est justement le remaining qui va donner sa valeur au NFP en fin charge (et donc la valeur du SOH a la voiture (et donc le km à 100%))

 

Alors si on calcul le SOH avec 3% de moins que la réalité, on dérive dans le temps à la baisse... vous voyez ou je veux en venir ? il vient peut-être de là le 1Km/mois. il faudrait investiguer plus dans cette direction j'ai l'impression qu'il y a des trucs sympa a trouver...

 

A noter que lorsque j'avais fait une charge complète, j'avais noté davantage de kWh en faisant l'intégration UI(t) que le remaining, ça explique sans doute. J'avais noté, de mémoire un peu plus de 1 kWh de différence. Et si je reprend mes 3%, on a 51.1kWh * 0.03 = 1.5 kWh! C'est les mêmes ordres de grandeur. ça semble pas mal

 

A confirmer :

- la valeur du totalCharge correspond exactement à l'intégration UI(t) lorsque la voiture est en charge

- regarder sur plusieurs charges si on retombe toujours sur ces 3%

- calculer ce % mais à la décharge cette fois, pour voir si ça vaux aussi 3%. Si c'est pas 3% -> il va y avoir une dérive dans le temps

 

Mais ce sera pour une autre fois  

 

 

 

[Jboll]

Le 07/07/2023 à 16:11, Jboll a dit :

A confirmer :

- la valeur du totalCharge correspond exactement à l'intégration UI(t) lorsque la voiture est en charge

- regarder sur plusieurs charges si on retombe toujours sur ces 3%

- calculer ce % mais à la décharge cette fois, pour voir si ça vaux aussi 3%. Si c'est pas 3% -> il va y avoir une dérive dans le temps

 

Mais ce sera pour une autre fois  

Pour suite,

(J'ai encore des trucs super sympa à vous montrer)

 

Regardons la 1ere ligne à confirmer :

- la valeur du totalCharge correspond exactement à l'intégration UI(t) lorsque la voiture est en charge

 

(Spoiler : OUI !!!!)

J'ai fait l'intégration UI(t) d'une trajet jusqu'à un SUC, puis recharge 80 -> 100% puis trajet retour (en jaune sur le graphique)

Et en gris-violet les données provenant du messages charge-décharge total

Ps : c'est tellement superposé qu'on voit même pas la distinction avec les deux courbes, mais l'autre est bien derrière :

 

Voyons en zoomant un peu :

Sur le trajet aller :

 

Lors du début de la charge :

 

La fin de charge :

 

Le trajet retour :

 

La fin du trajet 

 

Bref : j'en suis convaincu tellement que c'est nickel : Tesla fait bien le comptage des coulombs à partir de la tension / intensité et met ce résultat dans ces deux compteurs. L'un nommé totalCharge et l'autre totalDischarge. Comptabilisant ainsi l'ensemble des charges/décharges depuis le début de la voiture.

 

Donc ce que l'on voit ici, c'est bien l'énergie comptée qui rentre et qui sort de la batterie

 

Et alors le fameux remaining ? ça fait quoi si on rajoute cette courbe ? est-ce qu'il va se supperposer nikel aux autres courbe (avec des paliers) ou il va dériver dans le temps ? d'environ 3% ? ça donne envie de savoir hein  

 

 

Eh ben c'est parti  je rajoute le remaining en bleu, et voici ce que j'obtiens :

 

Bon ben ça dérive : au début c'est nickel :

 

 

et à la fin ça dérive grave :

 

A noter que la charge à 100% n'a rien synchronisé du tout ! les deux compteurs du BMS "nominal remaining" et "total(Dis)Charge" divergent au fur et à mesure du temps.

 

@tben c'est ce qui explique pourquoi quand tu fais l'intégration UI(t) tu diverges petit à petit du remaining : c'est pas une erreur de comptage de ta part

 

 

Le 07/07/2023 à 16:11, Jboll a dit :

- calculer ce % mais à la décharge cette fois, pour voir si ça vaux aussi 3%. Si c'est pas 3% -> il va y avoir une dérive dans le temps

ça donne envie de savoir, sur mes deux trajets (donc principalement en décharge) si je retombe sur ces 3%, ou pas

 

Eh bien c'est parti

 

1er trajet (aller vers le SUC)

 

Par intégration UI(t) : 43.3783 - 38.7786 = 4.5997 kWh

Par message Total(Dis)Charge : 43.378 - 38.782 = 4,596 kWh

Par message nominalEnergyRemaining : 43.38 - 38.74 = 4,61 kWh

 

Alors combien de % ?

-3 % comme en charge ? on va calculer ça :

4.61*100/4.596 => 3 %

 

Donc oui, quand on décharge, on est aussi à 3%. Sauf que c'est 3% de plus ! (et pas de moins comme en charge)

 

Autrement dit, quand on charge le remaining est pessimiste : il considère qu'on a chargé 3% de moins d'énergie dans la batterie. Et en décharge, il considère qu'il perd 3% de plus que ce qui est compté par le comptage des UI(t)

 

==> ça ressemble à une prise en compte empirique de la résistance interne de la batterie, qu'il évalue à 3% de perte, en charge ou en décharge

 

Pour le fun, je fais aussi le second trajet, car avec un SOC de 100%. Pour savoir si ce % est différent à 80 ou a 100% de SOC :

Par intégration UI(t) : 52.102 - 50.7498 = 1.3522 kWh

Par message Total(Dis)Charge : 52.157-50.746 = 1.411 kWh

Par message nominalEnergyRemaining : 51.38 - 50.12 = 1.26 kWh

 

Alors combien de % ?

1.411*100/1.26 =>  12%

 

Ouch... mais pourquoi 12% alors que je m'attendais à 3 % 

En plus, ça n'a pas de sens : la résistance interne doit être forte en fin de charge à 100% et faible en début de décharge depuis 100%

Donc je me serais attendu à 3% ou moins.

 

Là on a peut-être l'autre problème non résolu du 100% qui semble faire - je sais pas quoi - mais qui pertube les compteurs

 

Je laisse ça de côté pour l'instant

 

Par contre, ces 3% c'est un peu embêtant, parce que ça a l'air d'être une valeur empirique, et s'il elle est pas bien évalué, elle va faire dériver petit à petit le compteur remaining de sa vrai valeur (et donc le NFP ? il faudrait vérifier pour voir)

ça explique aussi peut-être pourquoi le buffer bas augmente si on regarde pas à 100% ? je ne sais pas trop pour l'instant

 

En tout cas, maintenant on sait pourquoi quand on intègre la tension et le courant par le temps on diverge du remaining

 

 

 

 

 

 

 

 

 

 

[MrFurieux]

Le 07/07/2023 à 16:11, Jboll a dit :

soit pile 3%

 

C'est marrant non ? de tomber pile sur une valeur...

ça l'air d'être une constante, sans doute mise là par Tesla ou CATL

Autrement dit, le remaining compte 3% de moins que le totalCharge

Autrement dit la voiture a bien détecté tout les kWh, mais 3% ne sont pas mis dans le compteur de remaining !

 

ça c'est une sacré découverte ! parce que c'est justement le remaining qui va donner sa valeur au NFP en fin charge (et donc la valeur du SOH a la voiture (et donc le km à 100%))

Oui c'est intéressant.

Est-ce que tu pourra faire le même test en charge lente ? Si c'est pareil, ça éliminerait l'hypothèse d'un rendement de charge de 97%.

Et ensuite dans le temps, si ça a un rapport avec le SOH le % va évoluer.

[MrFurieux]

Le 07/07/2023 à 18:53, Jboll a dit :

Autrement dit, quand on charge le remaining est pessimiste : il considère qu'on a chargé 3% de moins d'énergie dans la batterie. Et en décharge, il considère qu'il perd 3% de plus que ce qui est compté par le comptage des UI(t)

 

==> ça ressemble à une prise en compte empirique de la résistance interne de la batterie, qu'il évalue à 3% de perte, en charge ou en décharge

Que le total chargé / déchargé corresponde à l'intégration de UI, c'est normal, ça veut juste dire qu'il compte l'énergie électrique rentrant et sortant de la batterie. Par contre 3% fixe ça ne ressemble pas du tout aux pertes venant de la RI qui sont proportionnelles au carré de l'intensité, donc quasi nulles en charge lente et relativement élevée à 100 kW (plusieurs %).

Où est le zéro du nominalEnergyRemaining déjà, c'est bien quand le buffer bas est vide et pas à 0% écran ...?