OBD II DIY retours d'expérience sur un sniffeur de bus CAN

[MrFurieux]

Le 17/05/2023 à 10:23, Jboll a dit :

Ben ça dépend s'ils arrivent tous au même moment ou pas... si c'est homogènement réparti dans le temps il est possible de bosser en juste à temps, mais si c'est des burst de 500 messages par ms toutes les 100 ms c'est pas pareil

Les pics sont limités aussi par la bande passante du bus: à 500 kbits/s, avec un message (+ overhead du protocole) pesant de l'ordre de 100 bits, tu ne va pas recevoir plus de 5 messages par ms

 

Le 17/05/2023 à 10:23, Jboll a dit :

Ok, il faudra que j'en trouve une autre alors, celle de Monroe montre pas grand chose je trouve

Je n'en ai jamais vu d'autres. ET7 ici, MG ZS là, mais pas de désassemblage complet de la CATL Tesla, alors qu'il y en a bien plus dans la nature. C'est une idée que je rumine depuis un moment sans trop oser en parler: lancer une cagnotte en ligne pour financer une batterie d'occasion et un démontage. Plus derrière une réutilisation des cellules dans un stockage stationnaire DIY. Peut être que des gens comme La Chaine EV serait partants pour pousser l'idée ...?

[MrFurieux]

Le 18/05/2023 à 15:04, Jboll a dit :

Et c'est bien ce qui est constaté : elles chutent une fois la charge terminée à 3.4V

Et ça peut importe si on fait un équilibrage ou pas, c'est juste le comportement normal après une charge

 

Par contre l'équilibrage c'est donc un autre phénomène, mais je ne vois pas trop comment il marche sur nos LFP : vu la faible différences de tension des cellules, c'est pas facile de savoir celles qui sont plus chargées que d'autre rien qu'en se basant sur leurs tensions. Est-ce qu'il y a de la doc sur le sujet ? sur nos Model 3 LFP ?

3,4V c'est pour une charge de 100%. L'équilibrage intervient quand toutes les cellules ne sont pas à 100% en même temps, par ex si ta cellule "faible" est à 99% elles vont s'équilibrer à 99.X% çàd 3,3V au lieu de 3,4V, par exemple.

Pour les LFP les différences de tension sont faibles, sauf aux environs de 100% justement comme tu peux voir. C'est une des raisons possibles pour la demande de 100%.

[Jboll]

Le 18/05/2023 à 21:38, MrFurieux a dit :

lancer une cagnotte en ligne pour financer une batterie d'occasion et un démontage. Plus derrière une réutilisation des cellules dans un stockage stationnaire DIY. Peut être que des gens comme La Chaine EV serait partants pour pousser l'idée ...?

Il n'y a qu'un moyen de le savoir

 

Merci pour les recherches

[Jboll]

Le 18/05/2023 à 21:45, MrFurieux a dit :

3,4V c'est pour une charge de 100%. L'équilibrage intervient quand toutes les cellules ne sont pas à 100% en même temps, par ex si ta cellule "faible" est à 99% elles vont s'équilibrer à 99.X% çàd 3,3V au lieu de 3,4V, par exemple.

Pour les LFP les différences de tension sont faibles, sauf aux environs de 100% justement comme tu peux voir. C'est une des raisons possibles pour la demande de 100%

👍

[MrFurieux]

Le 18/05/2023 à 14:49, Jboll a dit :

Mon programme est terminé pour enregistrer une charge de 0 à 100%, j'ai noté les points suivants :

- Enregistrement de 6 types de messages différents, dont celui avec l'id 306 contenant la tension et l'intensité de la batterie haute voltage

- Ce filtrage + une compression des id vont me permettre d'enregistrer au maximum 654 heures dans un fichier de 4 Go (autant dire que c'est large)

Si tu veux gratter encore sur la taille des données, ce qui est toujours bénéfique pour les perfs, tu peux enregistrer l'écart de temps entre 2 messages plutôt que la valeur absolue. L'écart serait sur un octet, en réservant la valeur 255 pour le cas (rare) où il dépasse 254 ms, et là tu enregistres la valeur absolue (idem aussi au 1er message). Si les messages font en moyenne 2 octets ça fait ~40% d'économie (1+1+2 au lieu de 4+1+2).

 

Autre idée de compression si les messages sont souvent répétés, faire référence à un message précédent. Par ex, -1 dans le champ longueur = cf le message précédent (peut s'étendre aux N messages précédents en gardant un tableau des derniers messages en mémoire).

[Jboll]

Le 18/05/2023 à 23:48, MrFurieux a dit :

Si tu veux gratter encore sur la taille des données, ce qui est toujours bénéfique pour les perfs, tu peux enregistrer l'écart de temps entre 2 messages plutôt que la valeur absolue. L'écart serait sur un octet, en réservant la valeur 255 pour le cas (rare) où il dépasse 254 ms, et là tu enregistres la valeur absolue (idem aussi au 1er message). Si les messages font en moyenne 2 octets ça fait ~40% d'économie (1+1+2 au lieu de 4+1+2)

Oui j'y ai pensé, mais je me suis dit que enregistrer un delta pouvait cumuler une petite erreur au fur et a mesure (d'environ 500 us par message) ce qui pourrait être pas négligeable sur une durée de plusieurs heures comme je pensais l'utiliser. J'ai pensé aussi a faire un delta pendant x messages puis d'insérer le temps absolue pour se synchroniser a nouveau. Mais j'ai pas envie de prendre des risques de bugs dans les algo de resynchronisation. L'idée c'est d'enregistrer des valeurs mesurées, car pour chaque calcul il faudrait que je calcul la nouvelle précision. Là c'est plus simple : la précision du signal c'est son coeff multiplicateur.  

Au passage, en général les messages sont bien bourrés, c'est souvent du 8/8 octets utilisés

 

Le 18/05/2023 à 23:48, MrFurieux a dit :

Autre idée de compression si les messages sont souvent répétés, faire référence à un message précédent. Par ex, -1 dans le champ longueur = cf le message précédent (peut s'étendre aux N messages précédents en gardant un tableau des derniers messages en mémoire)

Les messages sont souvent répétés, oui,  mais pas avec les mêmes valeurs. J'avais aussi commencé a stocker une valeur calculé en wh toutes les 100ms plutôt qu'un message avec le voltage, l'intensité et d'autres infos toutes les 10ms. Gros gain en perceptive. Au moins diviser par 10! 
 

Mais j'ai tenté le coup avec juste un filtrage et ça passe très bien. Donc en l'état j'ai pas envie de prendre des risques d'erreurs en complexifiant le machin, surtout si le gain n'est pas évident pour mon cas d'utilisation. "Keep it simple, stupid" comme on dit 😁

[MrFurieux]

Le 19/05/2023 à 00:14, Jboll a dit :

Oui j'y ai pensé, mais je me suis dit que enregistrer un delta pouvait cumuler une petite erreur au fur et a mesure (d'environ 500 us par message) ce qui pourrait être pas négligeable sur une durée de plusieurs heures comme je pensais l'utiliser. 

En enregistrant la différence avec une valeur initiale il n'y a pas de dérive, le calcul est exact si on soustrait à chaque enregistrement. Non ?

[Jboll]

Le 19/05/2023 à 00:37, MrFurieux a dit :

En enregistrant la différence avec une valeur initiale il n'y a pas de dérive, le calcul est exact si on soustrait à chaque enregistrement. Non ?

Ça pour le coup c'est déjà ce qui est fait, le temps commence a 0 quand la carte est alimentée

Ce qui est permet de gagner 4 octets. Une date complète précise a la ms près aurait dû être de 8 octets

[MrFurieux]

Le 19/05/2023 à 07:49, Jboll a dit :

Ça pour le coup c'est déjà ce qui est fait, le temps commence a 0 quand la carte est alimentée

Ce qui est permet de gagner 4 octets. Une date complète précise a la ms près aurait dû être de 8 octets

C'est pas ce que je voulais dire, mais sans détails c'était pas clair.

Si tu reçois par ex des msg à 0,4 ms d'intervalle, les delta vont être +0, +0, +1, +0, +1, +0, +0, +1, etc

En comparant juste le temps du msg N à celui du msg N-1 on pourrait à la longue avoir une dérive comme tu dis.

Ce que je veux dire, c'est que tu as en mémoire à la fois le temps initial (zéro ou autre chose), et tes incréments. Si tu stockes dans une variable le cumul de tous tes incréments, tu peux à tout moment comparer avec le temps initial et éviter la dérive. Dans l'exemple au dessus, tu as un incrément total de +3 ms donc si le message suivant est à +8 par rapport au temps initial, tu sais que tu dois écrire +5, et l'erreur sera à coup sûr inférieure à 1ms.

[Jboll]

Le 19/05/2023 à 15:11, MrFurieux a dit :

C'est pas ce que je voulais dire, mais sans détails c'était pas clair.

Si tu reçois par ex des msg à 0,4 ms d'intervalle, les delta vont être +0, +0, +1, +0, +1, +0, +0, +1, etc

En comparant juste le temps du msg N à celui du msg N-1 on pourrait à la longue avoir une dérive comme tu dis.

Ce que je veux dire, c'est que tu as en mémoire à la fois le temps initial (zéro ou autre chose), et tes incréments. Si tu stockes dans une variable le cumul de tous tes incréments, tu peux à tout moment comparer avec le temps initial et éviter la dérive. Dans l'exemple au dessus, tu as un incrément total de +3 ms donc si le message suivant est à +8 par rapport au temps initial, tu sais que tu dois écrire +5, et l'erreur sera à coup sûr inférieure à 1ms.

Ok, oui c'est une bonne idée de réduction. Vu que les messages sont tout les 10ms max, un byte suffirait largement. Il faudra par contre définir un temps initial qui ne peux pas être l'uptime de la carte, car de mémoire il faut 600-700 ms d'initialisation avant de recevoir le premier message. Et 700 ça ne rentre pas dans un seul octet non signé, limité a 255 max. Mais ça doit pouvoir se faire, le gain espéré serait de 3 octets par message, ce qui n'est pas négligeable. Par contre si jamais il y a un soucis et que je reçois rien (ou que a un moment le temps d'écriture sur carte, dû a un changement de cluster ou que sais-je) est supérieure a 255 ms c'est mort. Ou sinon il faudrait que je réserve une valeur, par exemple 255, pour traiter ce cas particulier. Bref ça va devenir plus compliquer mais je pense que c'est possible. Moi ce que je vois c'est surtout que les messages ne sont plus indépendants les uns les autres et que pour décoder un message il faudra decoder correctement celui juste avant, et celui d'avant etc, et ça durant des millions des messages. Si un grain de sable s'incruste dans un message, c'est mort pour tout les messages qui suivent. Le gain a l'air bien, mais je préfère garder les messages indépendants, ça me rassure pour la tolérance aux pannes. 

 

Une autre idée, plus simple, c'est d'enlever le champ longueur, a vérifier mais je crois que pour ces messages leur taille est constante. Donc pas besoin de les envoyer a chaque message. Gain possible de 1 octet par message 

[MrFurieux]

Le 19/05/2023 à 18:21, Jboll a dit :

Ok, oui c'est une bonne idée de réduction. Vu que les messages sont tout les 10ms max, un byte suffirait largement. Il faudra par contre définir un temps initial qui ne peux pas être l'uptime de la carte, car de mémoire il faut 600-700 ms d'initialisation avant de recevoir le premier message. Et 700 ça ne rentre pas dans un seul octet non signé, limité a 255 max. Mais ça doit pouvoir se faire, le gain espéré serait de 3 octets par message, ce qui n'est pas négligeable. Par contre si jamais il y a un soucis et que je reçois rien (ou que a un moment le temps d'écriture sur carte, dû a un changement de cluster ou que sais-je) est supérieure a 255 ms c'est mort. Ou sinon il faudrait que je réserve une valeur, par exemple 255, pour traiter ce cas particulier.

D'abord une précision: je suis d'accord avec ton analyse "pas la peine de compliquer l'écriture et le décodage en cherchant une optimisation qui n'apporte rien de concret". L'esprit de ma remarque de départ sur la compression c'était de d'avoir en tête qu'il y a de la marge en cas de besoin, par ex si tu veux traiter plus de messages.

Sur l'horodatage: le point de départ peut simplement être le 1er enregistrement, ce qui donnerait exactement les mêmes temps décodés que ceux que tu as maintenant. Et en cas de délai >= 255, utiliser 255 + horodate comme dit précédemment. Mais comme tu dis ça complique, pour gagner 25% (4+1+8 => 1+1+8) bof. Mais ça deviendrait nettement plus intéressant si c'est combiné avec une compression des répétitions car dans cas cas au lieu de gagner 25% on gagne 250% (4+1 => 1+1).

 

Le 19/05/2023 à 18:21, Jboll a dit :

Moi ce que je vois c'est surtout que les messages ne sont plus indépendants les uns les autres et que pour décoder un message il faudra decoder correctement celui juste avant, et celui d'avant etc, et ça durant des millions des messages. Si un grain de sable s'incruste dans un message, c'est mort pour tout les messages qui suivent. Le gain a l'air bien, mais je préfère garder les messages indépendants, ça me rassure pour la tolérance aux pannes. 

Je ne sais pas si c'est une angoisse légitime, en cas de fichier corrompu tu risques d'avoir des problèmes de toute façon. Mais pour ce problème précis, il y a des solutions aussi, par ex des blocs de 100 messages commençant par un temps absolu.

 

Le 19/05/2023 à 18:21, Jboll a dit :

Une autre idée, plus simple, c'est d'enlever le champ longueur, a vérifier mais je crois que pour ces messages leur taille est constante. Donc pas besoin de les envoyer a chaque message. Gain possible de 1 octet par message 

Oui

[F4HFM]

Bonjour @MrFurieux et @Jboll.

Tout d'abord, merci pour ce beau fil très intéressant !

Et surtout, félicitations pour vos investigations 👌🤪.

 

Du coup, je déduis que le CAN disponible sur l'OBD est à 500kb/s, en trames standard (ID sur 11bits), et avec des trames multiplexées (pour remonter par exemple les 106 valeurs de tension sur 36 trames)

J'ai vu qu'il y a une DBC disponible, c'est une bonne nouvelle car par évident de déduire les données juste à partir des trames 🤪.

Merci à JoshWardell.

 

Une question, vous semblez avoir des soucis de pertes de trames.

Je ne sais pas comment fonctionne l'interface CAN (OBD-II CAN Bus Basic Dev Kit), mais si il contient un composant de décodage type driver CAN (MicroChip en faisait, mais sans doute d'autres), en général ces composants contiennent un petit buffer, et peuvent donc stocker quelques trames. Du coup, si l'interface "dépile" les messages, en mettant à disposition une PIN de réception, il doit être possible de lire une trame, puis une autre etc, sans perte (sauf bien sûr si la puissance de l'Arduino ne permet pas de dépiler aussi vite que les arrivée). Dans votre cas, vous indiquez relever un message environ une boucle sur 2, donc à priori le débit des trames est plus faible que la possibilité de traitement de l'Arduino.
Mais peut-être que l'interface n'a pas ou ne gère pas de buffer tampon?

 

Merci en tous cas pour votre partage, et encore félicitation pour ce (très gros) travail !

[F4HFM]

Bon, auto réponse, l'interface en question indique un circuit MCP2551 datasheet CCP2551, qui n'a que des pin TX/RX vers le décodeur, pas de fil d'interruption.
Donc à priori, on doit lire la liaison série en direct, pas de buffer sur ce composant.
Effectivement, si on ne lit pas assez vite, on perd des données...

IL est maintenant remplacé par des MCP2518FC (Datasheet MCP 2518), qui eux ont un buffer de 31 trames, et une Pin INT1 d'interruption sur réception. Là on peut imaginer un système de dépilage sans perte (si l'Arduino est capable de suivre le rythme bien sûr).

Mais ça ferait faire une interface...

[Jboll]

Le 21/05/2023 à 18:21, F4HFM a dit :

Bonjour @MrFurieux et @Jboll.

Tout d'abord, merci pour ce beau fil très intéressant !

Et surtout, félicitations pour vos investigations 👌🤪.

 

Du coup, je déduis que le CAN disponible sur l'OBD est à 500kb/s, en trames standard (ID sur 11bits), et avec des trames multiplexées (pour remonter par exemple les 106 valeurs de tension sur 36 trames)

J'ai vu qu'il y a une DBC disponible, c'est une bonne nouvelle car par évident de déduire les données juste à partir des trames 🤪.

Merci à JoshWardell.

 

Une question, vous semblez avoir des soucis de pertes de trames.

Je ne sais pas comment fonctionne l'interface CAN (OBD-II CAN Bus Basic Dev Kit), mais si il contient un composant de décodage type driver CAN (MicroChip en faisait, mais sans doute d'autres), en général ces composants contiennent un petit buffer, et peuvent donc stocker quelques trames. Du coup, si l'interface "dépile" les messages, en mettant à disposition une PIN de réception, il doit être possible de lire une trame, puis une autre etc, sans perte (sauf bien sûr si la puissance de l'Arduino ne permet pas de dépiler aussi vite que les arrivée). Dans votre cas, vous indiquez relever un message environ une boucle sur 2, donc à priori le débit des trames est plus faible que la possibilité de traitement de l'Arduino.
Mais peut-être que l'interface n'a pas ou ne gère pas de buffer tampon?

 

Merci en tous cas pour votre partage, et encore félicitation pour ce (très gros) travail !

Oui il y a bien un buffer pour la réception, mais c'est un buffer interne de 2 messages... (La taille du buffer n'est pas changeable)

Autant dire que c'est un petit buffer. 

Le problème c'est que le débit n'est pas constant, tu peux très bien passer de 1 message par ms a 5 messages par ms puis revenir a 2, puis 3, puis 1 etc. 

Alors quand c'est 1 message par ms c'est facile, pas de perte. Mais quand il y a 5 messages qui arrivent a le queue leu leu dans la même ms, c'est plus le même histoire, tu n'a pas le temps de traiter les premiers que les suivants se font écrasé par ceux d'après. 

 

Mais je te rassure, le problème de perte de message est maintenant résolu, en résumé la technique de filtrage marche très très bien et est la plus efficace

 

Et encore il y a plein d'autres idées d'améliorations que tu peux voir sur ce fil. C'est assez créatif et je pense efficace

(Interruptions, compression du message, buffer intermediaire ...)

 

C'est bien d'avoir dans sa besace des outils différents pour des usages différents

 

[Jboll]

Le 21/05/2023 à 18:46, F4HFM a dit :

Bon, auto réponse, l'interface en question indique un circuit MCP2551 datasheet CCP2551, qui n'a que des pin TX/RX vers le décodeur, pas de fil d'interruption.
Donc à priori, on doit lire la liaison série en direct, pas de buffer sur ce composant.
Effectivement, si on ne lit pas assez vite, on perd des données...

IL est maintenant remplacé par des MCP2518FC (Datasheet MCP 2518), qui eux ont un buffer de 31 trames, et une Pin INT1 d'interruption sur réception. Là on peut imaginer un système de dépilage sans perte (si l'Arduino est capable de suivre le rythme bien sûr).

Mais ça ferait faire une interface...

Tu regardes pas la bonne datasheet, le 2551 c'est pour l'émission, la réception ça utilise un MCP2515 et qui a bien une pin d'interruption :

https://ww1.microchip.com/downloads/en/DeviceDoc/MCP2515-Stand-Alone-CAN-Controller-with-SPI-20001801J.pdf

 

[MrFurieux]

Le 21/05/2023 à 18:21, F4HFM a dit :

Merci en tous cas pour votre partage, et encore félicitation pour ce (très gros) travail !

NB que le matériel et le code c'est @Jboll, je fais juste partie du groupe des commentateurs 🙂

Comme tu passes par là, tu as peut être un commentaire à faire sur la question des différences de tension dans son pack, en particulier la 60 qui se distingue ?

Le 15/05/2023 à 18:32, Jboll a dit :

J'ai l'impression que ce sont les cellules les plus proche du "+" qui se chargent le moins (sauf ma 60 qui est en plein milieu du pack) c'est à dire celles qui sont le plus usée ?!

Ma compréhension du montage du pack (106 cellules en série), est que la cellule qui a la tension la plus basse soit

1) a plus de capacité (= demande plus de courant pour être chargée à 100%)

2) est moins chargée que les autres au départ

En cherchant des infos je suis tombé sur cette vidéo que je trouve très bien. Elle explique pas mal de choses, y compris des rappels généraux sur ce genre de circuits électriques. Équilibrage actif / passif, par le haut ou par le bas, ....

[Jboll]

J'en profite aussi pour te demander ton avis @F4HFM sur deux autres sujets

 

Le premier c'est une expérience faite par @tben récemment, il a descendu a 0% de SOC et a fait une recharge complète a 100% sans s'arrêter. Mais je trouve étrange que en début de charge, c'est a dire a 0%, le BMS lui ait indiquée une fin de charge 8km en dessous de son autonomie estimé. Sa charge est monté a 99% a 10h30 et il a passé environ 30 ou 40 minutes a faire le dernier pourcent. Descendre a 0% ça a complètement paumé le BMS. A-t-on avis, pourquoi? 

 

En toute honnêteté, je me demande si leSOC est évalué juste par comptable des coulombs, si oui, pourquoi serait-il aussi paumé?

 

Autre sujet, lié, dont j'aimerai avoir ton avis, c'est pourquoi si je trace le graphique (kWh remaning-buffer bas)/autonomie affiché en km, j'obtiens une courbe dont une empreinte de la tension semble être dedans. Si c'est juste du comptage de coulomb il n'y a pas de raison que ce soit le cas, si?

 

[F4HFM]

Le 21/05/2023 à 19:49, MrFurieux a dit :

Ma compréhension du montage du pack (106 cellules en série), est que la cellule qui a la tension la plus basse soit

1) a plus de capacité (= demande plus de courant pour être chargée à 100%)

2) est moins chargée que les autres au départ

En cherchant des infos je suis tombé sur cette vidéo que je trouve très bien. Elle explique pas mal de choses, y compris des rappels généraux sur ce genre de circuits électriques. Équilibrage actif / passif, par le haut ou par le bas, ....

1): oui, il y a toujours un peu de dispersion entre les capacités des différentes cellules. Mais je crois que c'est assez faible (quelques %). Mais ça peut expliquer une cellule qui, ayant reçu la même quantité d'énergie, a une tension plus faible car pas encore pleine.

2) oui, si on part déséquilibré, on "remonte" toutes les cellules d'à peu près la même quantité d'énergie (toutes les cellules en série sont traversées par exactement le même courant, donc récupèrent le même nombre d'A.h)

3) par contre il y a un autre effet: chaque cellule n' pas la même résistance interne. Je m'explique: on peut modéliser une cellule par un condensateur, en série avec une résistance interne (et en // avec une résistance d'auto-décharge). Et c'est là que ça dérape: si on traverse deux cellules avec le même courant, la tension résultante au bord de la capa n'est pas exactement la même. Si on met une tension U au borne de 2 cellules traversées par un courant I, elles voient chacune I, mais la tension n'est pas exactement U/2, selon les variations de capa et résistance interne.

C'est d'ailleurs ce qi explique que deux cellules peuvent avoir la même tension à vide, mais la chute de tension en débitant du courant n'est pas la même pour les deux, elle est de dU = Rinterne * I.

 

Dans le cas de la cellule 60, elle voit toujours le même courant que les autres, mais si sa résistance interne est plus forte, elle se décharge plus vite et se recharge plus lentement. Et on ne va pas pouvoir y faire grand chose, au global c'est elle qui va limité la capacité globale de tout le pack. J'ai vu des considérations sur les cellules en début/milieu/bout de chaîne, pour moi ça ne change rien à priori; elles voient le même courant. Le fait qu'une se décharge plus ou moins vite est lié à elle même, pas à sa position dans le pack. Ou du moins je crois, je n'ai jamais vu de différence quand je mettais des cellules (en fait des "pack" de 4 série / x parallèle) en série, qu'on les mette en 1-2-3 ou 1-3-2 ne changeait rien. Il y a peut être des effets, mais e ne vois pas lesquels.

Après, il y a toujours une cellule plus faible dans un pack, et c'est elle qui va limiter tout le pack.

[F4HFM]

Le 21/05/2023 à 20:08, Jboll a dit :

Autre sujet, lié, dont j'aimerai avoir ton avis, c'est pourquoi si je trace le graphique (kWh remaning-buffer bas)/autonomie affiché en km, j'obtiens une courbe dont une empreinte de la tension semble être dedans. Si c'est juste du comptage de coulomb il n'y a pas de raison que ce soit le cas, si?

Je ne connais pas vraiment la gestion buffer bas par Tesla.

Donc déjà premier point, le BMS va effectivement calculer un SOC "global" du pack, entre 0 et 100%.

Le 100% va correspondre à toutes les cellules à leur plus haut niveau après équilibrage. Le buffer haut, de ce que j'ai compris, ça revient à dire on ne va pas au-delà de 98%, pour préserver les batteries, et on affiche 100%.

Le buffer bas, c'est dire on ne descend pas en dessous de 5%, et on affiche 0%.

Du coup, la plage 5-98% est "mappée" en 0-100%. C'est une méthode. Perso, dans mes applications on calculait le SOC réel, mais c'était le calculateur du véhicule qui limitait la plage d'utilisation, en inhibant la traction par exemple en dessous de 5%. On ne pouvait plus avancer, mais la batterie restait fonctionnelle pour le DC/DC et d'autres fonctions. Et si on descendait à 0%, c'est le BMS qui ouvrait les relais et isolait la batterie.

Mais ici Tesla se laisse des marges, d'après ce que j'ai compris ça permet de "remettre de l'autonomie" quand la capacité de la batterie baisse, on décale le seuil bas de 5% à 4% etc. C'est une méthode...

 

Pour en revenir à la courbe remaining buffer vs autonomie affichée, là c'est encore une autre question. Perso on n'affichait pas des autonomie, par protection juridique (si tu affiche 200km restant et que le client n'en fait que 195, il est en droit de se plaindre 😠. Donc autant n'afficher que le SOC 😇).

J'aivais cru comprendre que l'affichage était une bête proportion autonomie = SOC*conso  officielle, ce qui fait que pour un niveau d'énergie donné on affiche un nombre de km.

Mais effectivement, j'ai vu aussi que les km affichés à SOC=100% variaient avec la capacité réelle restante, dégradation comprise. Donc km = SOC * SOH *( autonomie neuve). Donc ça prend en compte la dégradation (ce qui permet du coup d'estimer cette dégradation en faisant une charge à 100%).

Après, le SOC est quand même lié à la tension, la courbe U = f(SOC) est pratiquement une droite (très plate) entre 5 et 95%. Donc ça peut expliquer que tu trouves un lien. En général on ne se sert pas de la tension pour calculer le SOC (car en fait elle varie beaucoup plus avec la température par exemple qu'avec le SOC). Mais sur un trajet à conditions de T° constante (d'autant plus si la batterie est régulée à 25°), on retrouve une corrélation tension/SOC. Tension globale du pack, ce qui revient à une tension moyenne des cellules*106, et pas tension d'une cellule qui elle va varier plus...

Mais encore une fois je n'en sais rien, car la façon de calculer peut varier d'un BMS à l'autre. Par contre dans les LFP, entre les deux extrêmes on fait à ma connaissance toujours du calcul en comptage de Coulomb, c'est la méthode la plus fiable. Après, il y a sans doute des algos encore plus rusés, car e problème du comptage c'est qu'on accumule les erreurs, et que si on ne va jamais à 100% ou 0%, le calcul dur SOC par le BMS va finir par dériver. C'est je crois le problème dans les batteries stationnaires, qui sont toujours utilisées sur une plage restreinte, genre 30%-70%, et je crois qu'il y a des procédures de recalage du calcul de temps en temps (et un équilibrage par la même occasion). Mais ce n'est pas un domaine que je connais...

[MrFurieux]

Le 21/05/2023 à 21:37, F4HFM a dit :

3) par contre il y a un autre effet: chaque cellule n' pas la même résistance interne. Je m'explique: on peut modéliser une cellule par un condensateur, en série avec une résistance interne (et en // avec une résistance d'auto-décharge). Et c'est là que ça dérape: si on traverse deux cellules avec le même courant, la tension résultante au bord de la capa n'est pas exactement la même. Si on met une tension U au borne de 2 cellules traversées par un courant I, elles voient chacune I, mais la tension n'est pas exactement U/2, selon les variations de capa et résistance interne.

C'est d'ailleurs ce qi explique que deux cellules peuvent avoir la même tension à vide, mais la chute de tension en débitant du courant n'est pas la même pour les deux, elle est de dU = Rinterne * I.

 

Dans le cas de la cellule 60, elle voit toujours le même courant que les autres, mais si sa résistance interne est plus forte, elle se décharge plus vite et se recharge plus lentement. Et on ne va pas pouvoir y faire grand chose, au global c'est elle qui va limité la capacité globale de tout le pack. J'ai vu des considérations sur les cellules en début/milieu/bout de chaîne, pour moi ça ne change rien à priori; elles voient le même courant. Le fait qu'une se décharge plus ou moins vite est lié à elle même, pas à sa position dans le pack. Ou du moins je crois, je n'ai jamais vu de différence quand je mettais des cellules (en fait des "pack" de 4 série / x parallèle) en série, qu'on les mette en 1-2-3 ou 1-3-2 ne changeait rien. Il y a peut être des effets, mais e ne vois pas lesquels.

Après, il y a toujours une cellule plus faible dans un pack, et c'est elle qui va limiter tout le pack.

Oui il peut y avoir des différences de RI, mais dans le cas de sa cellule 60, à mon avis c'est pas une question de RI car il a des courbes ressemblantes en charge lente (3 kW) et rapide (SUC). Même au dessus de 80%, le SUC envoie 30 kW ou plus, l'effet Joule serait 100x plus fort, on verrait une différence énorme (je pense).

Pour la question de pourquoi on dit que les cellules en tête souffrent plus, je ne sais pas non plus. 

Modifié mai 21, 2023 par MrFurieux

[F4HFM]

Oui, effectivement, il doit y avoir un autre phénomène. Mais lequel, bonne question 😉 🤪.
Il faudrait un espion chez Tesla pour nous expliquer toutes les subtilités.
Passionnant en tous cas !

Et heureusement qu'on ne se pose pas ses questions en utilisant nos voitures 😎

[MrFurieux]

Le 21/05/2023 à 22:00, F4HFM a dit :

Je ne connais pas vraiment la gestion buffer bas par Tesla.

Donc déjà premier point, le BMS va effectivement calculer un SOC "global" du pack, entre 0 et 100%.

Le 100% va correspondre à toutes les cellules à leur plus haut niveau après équilibrage. Le buffer haut, de ce que j'ai compris, ça revient à dire on ne va pas au-delà de 98%, pour préserver les batteries, et on affiche 100%.

Le buffer bas, c'est dire on ne descend pas en dessous de 5%, et on affiche 0%.

Du coup, la plage 5-98% est "mappée" en 0-100%. C'est une méthode. Perso, dans mes applications on calculait le SOC réel, mais c'était le calculateur du véhicule qui limitait la plage d'utilisation, en inhibant la traction par exemple en dessous de 5%. On ne pouvait plus avancer, mais la batterie restait fonctionnelle pour le DC/DC et d'autres fonctions. Et si on descendait à 0%, c'est le BMS qui ouvrait les relais et isolait la batterie.

Mais ici Tesla se laisse des marges, d'après ce que j'ai compris ça permet de "remettre de l'autonomie" quand la capacité de la batterie baisse, on décale le seuil bas de 5% à 4% etc. C'est une méthode...

Pour Tesla, on est plutôt sur du 5-99+% avec un très petit buffer haut. La méthode "remettre de l'autonomie" c'est pour d'autres comme Huyndai / Kia qui partent avec un buffer haut entre 5 et 10% et qui le mangent progressivement quand le SOH baisse - par contre ils ne mettent pas de buffer bas, il ne faut pas jouer avec le 0%.

 

Le 21/05/2023 à 22:00, F4HFM a dit :

J'aivais cru comprendre que l'affichage était une bête proportion autonomie = SOC*conso  officielle, ce qui fait que pour un niveau d'énergie donné on affiche un nombre de km.

Mais effectivement, j'ai vu aussi que les km affichés à SOC=100% variaient avec la capacité réelle restante, dégradation comprise. Donc km = SOC * SOH *( autonomie neuve).

Oui c'est ça, en gros. Mais comment est-ce que le BMS fait pour estimer le SOH avec des batteries qui très souvent n'approchent jamais le 0%, ça parait bien mystérieux...

[Jboll]

Le 21/05/2023 à 22:00, F4HFM a dit :

Je ne connais pas vraiment la gestion buffer bas par Tesla.

Donc déjà premier point, le BMS va effectivement calculer un SOC "global" du pack, entre 0 et 100%.

Le 100% va correspondre à toutes les cellules à leur plus haut niveau après équilibrage. Le buffer haut, de ce que j'ai compris, ça revient à dire on ne va pas au-delà de 98%, pour préserver les batteries, et on affiche 100%.

Le buffer bas, c'est dire on ne descend pas en dessous de 5%, et on affiche 0%.

Du coup, la plage 5-98% est "mappée" en 0-100%. C'est une méthode. Perso, dans mes applications on calculait le SOC réel, mais c'était le calculateur du véhicule qui limitait la plage d'utilisation, en inhibant la traction par exemple en dessous de 5%. On ne pouvait plus avancer, mais la batterie restait fonctionnelle pour le DC/DC et d'autres fonctions. Et si on descendait à 0%, c'est le BMS qui ouvrait les relais et isolait la batterie.

Mais ici Tesla se laisse des marges, d'après ce que j'ai compris ça permet de "remettre de l'autonomie" quand la capacité de la batterie baisse, on décale le seuil bas de 5% à 4% etc. C'est une méthode...

 

Pour en revenir à la courbe remaining buffer vs autonomie affichée, là c'est encore une autre question. Perso on n'affichait pas des autonomie, par protection juridique (si tu affiche 200km restant et que le client n'en fait que 195, il est en droit de se plaindre 😠. Donc autant n'afficher que le SOC 😇).

J'aivais cru comprendre que l'affichage était une bête proportion autonomie = SOC*conso  officielle, ce qui fait que pour un niveau d'énergie donné on affiche un nombre de km.

Mais effectivement, j'ai vu aussi que les km affichés à SOC=100% variaient avec la capacité réelle restante, dégradation comprise. Donc km = SOC * SOH *( autonomie neuve). Donc ça prend en compte la dégradation (ce qui permet du coup d'estimer cette dégradation en faisant une charge à 100%).

Après, le SOC est quand même lié à la tension, la courbe U = f(SOC) est pratiquement une droite (très plate) entre 5 et 95%. Donc ça peut expliquer que tu trouves un lien. En général on ne se sert pas de la tension pour calculer le SOC (car en fait elle varie beaucoup plus avec la température par exemple qu'avec le SOC). Mais sur un trajet à conditions de T° constante (d'autant plus si la batterie est régulée à 25°), on retrouve une corrélation tension/SOC. Tension globale du pack, ce qui revient à une tension moyenne des cellules*106, et pas tension d'une cellule qui elle va varier plus...

Mais encore une fois je n'en sais rien, car la façon de calculer peut varier d'un BMS à l'autre. Par contre dans les LFP, entre les deux extrêmes on fait à ma connaissance toujours du calcul en comptage de Coulomb, c'est la méthode la plus fiable. Après, il y a sans doute des algos encore plus rusés, car e problème du comptage c'est qu'on accumule les erreurs, et que si on ne va jamais à 100% ou 0%, le calcul dur SOC par le BMS va finir par dériver. C'est je crois le problème dans les batteries stationnaires, qui sont toujours utilisées sur une plage restreinte, genre 30%-70%, et je crois qu'il y a des procédures de recalage du calcul de temps en temps (et un équilibrage par la même occasion). Mais ce n'est pas un domaine que je connais...

Merci pour toutes ces infos 👍

[Jboll]

Le 21/05/2023 à 21:37, F4HFM a dit :

au global c'est elle qui va limité la capacité globale de tout le pack

Hmmm après réflexion, je dirai que c'est plutôt l'inverse. Vu que la cellule 60 a la plus faible tension, c'est pas elle qui va arrêter la charge. Donc c'est pas elle qui va limiter la capacité globale. Celle qui va limiter la charge c'est la plus chargée, celle avec la plus haute tension

[Jboll]

Le 21/05/2023 à 22:00, F4HFM a dit :

le SOC est quand même lié à la tension

Si le calcul du SOC est fait par comptage des coulombs, le SOC est donc lié a l'intensité et pas a la tension. Non ?

SOC = capacité actuelle / capacité total

 

Avec la capacité est défini Ah

 

Il n'y a pas de tension dans le calcul

 

J'ai loupé quelque chose dans le raisonnement ?