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

[tben]

Le 31/05/2023 à 20:32, Jboll a dit :

Je me demande si Tesla utilise la tension ou s'ils se contentent d'une valeur fixe pour ce remaining

Je cherche, je n'ai pas encore trouvé

[MrFurieux]

Le 31/05/2023 à 20:50, tben a dit :

sauf si l'erreur est aleatoire en gaussienne autour de la valeur réelle.

Oui ou de façon générale si la moyenne de l'erreur est nulle et qu'on intègre ensuite sur un grand nombre de mesures, ça fait une sorte de bruit numérique qui est lissé par l'intégration. Par contre il faut faire attention aux cas où on calcule avec des erreurs qui peuvent au contraire être amplifiées par le calcul, par ex une soustraction entre deux valeurs proches avec un résultat qui ne contient plus que du bruit. C'est le genre de choses à vérifier quand on a des résultats difficiles à expliquer.

[tben]

Oui, quoique que tu fasses

Le 01/06/2023 à 00:23, MrFurieux a dit :

il faut faire attention

 

[MrFurieux]

Le 01/06/2023 à 10:13, tben a dit :

Oui, quoique que tu fasses

Si je le mentionne, c'est que c'est un sujet spécialement piégeux. En général on pense aux erreurs de mesure (ici on ne les connait pas mais on suppose qu'on a la précision suffisante), aux erreurs de représentation (ce que fait @Jboll), mais assez souvent ou néglige les erreurs de calcul dans le code en supposant que les 16 chiffres significatifs de la double précision nous mettent à l'abri.

Malheureusement on n'est jamais à l'abri, j'ai cité le cas de la soustraction, mais il y a aussi le cas de l'addition d'un petit nombre et d'un grand nombre, et il y a d'autres cas. Comme les pertes de précision se cumulent à chaque opération, sur un calcul complexe on peut avoir des surprises.

Je ne dis pas que c'est ce qui se passe dans son cas, mais par ex avoir une très longue suite de mesures avec un cumul à chaque point et une division finale est un cas typique de calcul à risque.

[Jboll]

Le 01/06/2023 à 11:08, MrFurieux a dit :

Si je le mentionne, c'est que c'est un sujet spécialement piégeux. En général on pense aux erreurs de mesure (ici on ne les connait pas mais on suppose qu'on a la précision suffisante), aux erreurs de représentation (ce que fait @Jboll), mais assez souvent ou néglige les erreurs de calcul dans le code en supposant que les 16 chiffres significatifs de la double précision nous mettent à l'abri.

Malheureusement on n'est jamais à l'abri, j'ai cité le cas de la soustraction, mais il y a aussi le cas de l'addition d'un petit nombre et d'un grand nombre, et il y a d'autres cas. Comme les pertes de précision se cumulent à chaque opération, sur un calcul complexe on peut avoir des surprises.

Je ne dis pas que c'est ce qui se passe dans son cas, mais par ex avoir une très longue suite de mesures avec un cumul à chaque point et une division finale est un cas typique de calcul à risque.

Ce n'est pas la précision de la représentation que j'ai évalué, mais la précision du message envoyé par la bus

 

Pour la précision de la représentation, il suffit de zoomer sur le graphique

 

Vu la fourchette, je pense que la vrai valeur est bien entre les deux valeurs min/max, avec une forte proba que la valeur soit sur la moyenne, sans doute une gaussienne oui

 

Pour le calcul des puissances, le calcul est fait sur un double, j'ai pas plus précis, et je pense pas qu'ils aient non plus

 

Ce qui fait surtout faire attention c'est sur des multiplications de nombre extrêmes (comprendre: un nombre a virgule très petit, avec un nombre entier très grand. Ex: 0.00000000001234 x 123400000000000.0) mais on est pas dans ce cas là : tout est petit

 

 

[Jboll]

Recharge à 100% effectuée cette nuit, je passe de 404 Km (26 mai) à 402 Km (1 Juin)

Mon NFP est passé de 51.5 kWh (lors de la recharge 0->100% du 26 mai) à 51.24 kWh (1er Juin de 85->100%)

J'ai également fait la mise à jour Tesla entre temps (que cela faisait des semaines qu'il me tanné avec ça)

 

Graphique représentant mon NFP, à gauche la recharge du 26 Mai, à droite celle du 1er Juin :

 

Pendant la recharge du 1er Juin, mon NFP a oscillé pendant la charge entre 51,26 et 51,24 pour s'arrêter sur 51,24 avec 90% de 51,24 et 10% parcellaire de 51,26 :

Zoom :

 

 

Alors, déjà je suis passé de 51.5 à 51.26 en début de charge sans trop savoir pourquoi (à part la mise à jour ?)

 

Et j'aimerai savoir si certains d'entre vous, avez une idée de pourquoi ça oscille comme ça pendant cette dernière charge ?

 

On pourrait se dire : c'est juste une histoire de seuil : il suffit qu'une mesure dépasse légèrement d'un seuil alors c'est 51.26, et si c'est légèrement en dessous alors c'est 51.24

Ok mais dans ce cas, ça voudrait dire qu'il y a des mesures très régulièrement et avec une précision pas top

 

@tben m'a plusieurs fois dit que ça marche par palier, ok ici le palier serait de 0.02 kWh. Mais ça explique pas pourquoi ça oscille à l'intérieur d'un palier, quand on regarde la courbe du remaining, on a également ces escaliers :

 

Si je zoom, on voit bien qu'il y a une mise à jour par palier, mais il y a aussi une mise à jour à l'intérieur de ce même palier

Zoom :

Donc il y a bien une mesure pour chaque points (vu que chaque points a une valeur différente)

 

Alors là c'est incompréhensible pour moi, pourquoi ça fait pas ce que j'ai dessiné en blanc : 

 

Donc je ne comprend pas pourquoi ça oscille à l'intérieur d'un palier (un palier fait 3 minutes soit dit en passant)

ni qu'elle serait la vrai valeur s'il n'y avait pas de palier

 

Intuitivement je me dit çà:

 

Mais je comprend pas pourquoi les autres palier ne sont pas affecté (il y a un palier sur 4 d'affecté)

 

 

 

Et puis si c'est vraiment la droite blanche la vérité, pourquoi il n'y a pas une oscillation plus grande sur ce palier ?

Ou dit autrement, pourquoi ça fait pas ça (en rouge) :

 

Leurs algo m'échappe

 

Modifié juin 1, 2023 par Jboll
Dsl j'ai enregistré trop vite, erreur de raccourci clavier

[LIION]

Le 31/05/2023 à 14:59, MrFurieux a dit :

En mettant de côté l'aspect théorique, ça voudrait dire entre autres qu'on aurait une capacité différente suivant que la charge est lente ou rapide, ce qui n'est pas ce qu'on constate. Comment est-ce que tu relies ces graphiques à la réalité ? Tu es sûr qu'il ne s'agit pas de dégradation ?

Je pense que dans les faits on ne le mesure pas assez précisément d'autant plus que les cas où on pourrait s'en apercevoir sont rares (inexistant?).

sur un prise on a faire du 3kW, soit C/15 => capa max

au mieux en AC on est à 11kW=>C/5 différence de capa négligeable

En DC il faudrait tester du 20-40kW (peut être encore bon en 50KW) car au dessus la batterie va chauffer, voire être preconditionnée et là la capa accessible à 45°C est meilleur qu'à l'ambiante!

Si quelqu'un peut charger en DC vers 20kW et veut se dévouer pour faire 1 full charge pour comparer à du 3kW on aurait la réponse☺️

edit : et aussi ne pas attendre une fois le 100% en fait car dans ce cas la charge ralentie (peut être se fixer une limite à 90%?)

Modifié juin 1, 2023 par LIION
precision

[MrFurieux]

Le 01/06/2023 à 18:45, LIION a dit :

Je pense que dans les faits on ne le mesure pas assez précisément d'autant plus que les cas où on pourrait s'en apercevoir sont rares (inexistant?).

sur un prise on a faire du 3kW, soit C/15 => capa max

au mieux en AC on est à 11kW=>C/5 différence de capa négligeable

En DC il faudrait tester du 20-40kW (peut être encore bon en 50KW) car au dessus la batterie va chauffer, voire être preconditionnée et là la capa accessible à 45°C est meilleur qu'à l'ambiante!

Si quelqu'un peut charger en DC vers 20kW et veut se dévouer pour faire 1 full charge pour comparer à du 3kW on aurait la réponse☺️

edit : et aussi ne pas attendre une fois le 100% en fait car dans ce cas la charge ralentie (peut être se fixer une limite à 90%?)

Je ne suis pas sûr de comprendre le test que tu veux faire, sur chargeur rapide  la LFP 55 approche des 100 kW en moyenne, et des C/2 au delà de 90% de SOC. Les graphiques que tu postes annoncent des variations de capacité qui dépassent 30% entre charge lente et rapide, le contraste est amusant avec les tests de @Jboll qui essaie d'expliquer 0,5% de différence de capacité en supposant implicitement que la méthode de charge n'a pas tellement d'influence. OK la batterie va chauffer en charge rapide, mais dans les courbes à 10C de ton graphique la cellule va chauffer aussi non ? Sinon, même en départ à froid on peut charger à 20/30 kW, là encore sans différence notable de capacité, et heureusement, ça serait le drame sinon.

[MrFurieux]

Le 01/06/2023 à 13:36, Jboll a dit :

Alors, déjà je suis passé de 51.5 à 51.26 en début de charge sans trop savoir pourquoi (à part la mise à jour ?)

 

Et j'aimerai savoir si certains d'entre vous, avez une idée de pourquoi ça oscille comme ça pendant cette dernière charge ?

 

On pourrait se dire : c'est juste une histoire de seuil : il suffit qu'une mesure dépasse légèrement d'un seuil alors c'est 51.26, et si c'est légèrement en dessous alors c'est 51.24

Ok mais dans ce cas, ça voudrait dire qu'il y a des mesures très régulièrement et avec une précision pas top

Proposition d'explication: le NFP est une estimation, pas une mesure, et dans ce cas c'est pas étonnant qu'il oscille en fonction de paramètres qui ne sont pas tous croissants. Pareils dans les paliers, la valeur que tu as peut combiner des mesures et des estimations dans un calcul dont tu ne vois que le résultat.

[MrFurieux]

Le 01/06/2023 à 12:59, Jboll a dit :

Ce n'est pas la précision de la représentation que j'ai évalué, mais la précision du message envoyé par la bus

 

Pour la précision de la représentation, il suffit de zoomer sur le graphiquest petit

C'est une représentation aussi, celle du message du bus. Avant ça il y a en a une autre, celle de la mesure stockée par le BMS. Et après il y en a une 3eme (ou plus), les flottants que tu manipules. A noter aussi pour le message du bus, en principe l'émetteur va utiliser un encodage qui a une précision supérieure à celle de la mesure (que tu ne connais pas), et qui va être la vraie incertitude en entrée de ton calcul.

 

Le 01/06/2023 à 12:59, Jboll a dit :

Pour le calcul des puissances, le calcul est fait sur un double, j'ai pas plus précis, et je pense pas qu'ils aient non plus

 

Ce qui fait surtout faire attention c'est sur des multiplications de nombre extrêmes (comprendre: un nombre a virgule très petit, avec un nombre entier très grand. Ex: 0.00000000001234 x 123400000000000.0) mais on est pas dans ce cas là : tout est petit

C'est rare d'avoir plus précis que le double. Tu donnes un autre exemple de calcul qui peut poser pb, mais dans ton cas "tout est petit", il faut se méfier aussi.

Exemple: tu mesures toutes les 10 ms pendant 10h, tu as 36 millions de valeurs "toutes petites". Mettons que tu les additionnes dans une boucle, tu vas perdre environ 7 chiffres de précision rien de dans cette opération parce que ton accumulateur va finir par contenir une grande valeur à laquelle tu ajoutes des petites valeurs. Et si jamais tu utilises par accident un flottant simple précision au lieu d'un double, ou si tu fais d'autres opérations derrière, tu peux te retrouver au final avec moins de 4 chiffres significatifs et le type d'écart que tu constates.

Modifié juin 1, 2023 par MrFurieux

[Jboll]

Le 01/06/2023 à 19:35, MrFurieux a dit :

Mettons que tu les additionnes dans une boucle, tu vas perdre environ 7 chiffres de précision rien de dans cette opération parce que ton accumulateur va finir par contenir une grande valeur à laquelle tu ajoutes des petites valeurs. Et si jamais tu utilises par accident un flottant simple précision au lieu d'un double, ou si tu fais d'autres opérations derrière, tu peux te retrouver au final avec moins de 4 chiffres significatifs et le type d'écart que tu constates.

Bien essayé, mais ça colle pas: c'est bien un double, je ne fait rien derrière, et 50 c'est pas un grand nombre. Surtout que si j'ai cette erreur le BMS la fera sûrement également, difficile de faire plus précis qu'un double

 

Par acquis de conscience, il existe des calcul strict en Java, je vais regarder pour voir si ça change quelque chose...

 

Et puis ça n'explique pas pourquoi j'ai pas le même pourcentage d'erreur entre lesAh et les kWh, si je fais une erreur ça devrait être dans les deux. La seule différence c'est la multiplication en plus (UxI)

 

Mais avec la fourchette que j'ai mis c'est tellement gros qu'il ne peut pas avoir d'erreur plus important que ça, non j'y crois pas, il y a vraiment autre chose

[MrFurieux]

Le 01/06/2023 à 22:47, Jboll a dit :

Bien essayé, mais ça colle pas: c'est bien un double, je ne fait rien derrière, et 50 c'est pas un grand nombre. Surtout que si j'ai cette erreur le BMS la fera sûrement également, difficile de faire plus précis qu'un double

 

Par acquis de conscience, il existe des calcul strict en Java, je vais regarder pour voir si ça change quelque chose...

 

Et puis ça n'explique pas pourquoi j'ai pas le même pourcentage d'erreur entre lesAh et les kWh, si je fais une erreur ça devrait être dans les deux. La seule différence c'est la multiplication en plus (UxI)

 

Mais avec la fourchette que j'ai mis c'est tellement gros qu'il ne peut pas avoir d'erreur plus important que ça, non j'y crois pas, il y a vraiment autre chose

C'était un exemple illustratif d'un pb de calcul qui peut passer inaperçu, je ne dis pas que c'est ce que tu as fait dans ton code (ça me fait penser qu'il faut que je le regarde, je crois que tu l'as posté dans l'autre sujet). Mais vu ta remarque sur le BMS qui ferait la même erreur, j'ai l'impression que ce que je dis n'est pas très clair: c'est un problème de calcul. Si le BMS fait le même calcul avec des entiers 64 bits il n'aura pas ce problème, vu que pour ce type d'addition le résultat serait exact avec des entiers.

Pour les Ah / Wh tu peux très bien avoir des erreurs différentes: si une partie de l'erreur porte sur U elle ne se verra que dans les Wh.

 

 

[Jboll]

Le 01/06/2023 à 19:26, MrFurieux a dit :

Proposition d'explication: le NFP est une estimation, pas une mesure, et dans ce cas c'est pas étonnant qu'il oscille en fonction de paramètres qui ne sont pas tous croissants. Pareils dans les paliers, la valeur que tu as peut combiner des mesures et des estimations dans un calcul dont tu ne vois que le résultat.

Oui clairement c'est un calcul, mais pas que...

 

J'ai l'impression qu'il y a deux paramètres, un qui est évalué toute les 3 minutes(les paliers) et un quasiment chaque seconde(entre les paliers). 

 

Celui des paliers a un poids au mois 10 fois supérieur à l’autre

 

comme cette courbe représente le remaining, et que je suis en charge, forcément ça monte de manière constante en réalité. 
mais on voit des descentes très légère sur le graphique. Pourtant le tension est positive, on est toujours en charge, aucune raison d’avoir une puissance qui serait tirée de la batterie au lieu d’être mise dedans. Donc pas de raison que ça diminue. 

donc : le remaining c’est pas un cumul de tension x intensité

 

Mais, pour les mise a jour dans le palier, c’est une mesure imprécise qui fait  osciller légèrement cette courbe 

 

Pour les paliers maintenant,

S'il y avait une somme des tensions et des intensités toutes les 10ms comme je fait, pourquoi ils se serait embêté a faire des paliers? Pourquoi ne pas envoyer tout simplement ce cumul ? Ce serait plus précis. 

 

ce qui pourrait expliquer que le pallier soient aussi long, 3 minutes tout de même, c’est le temps d'attendre que la mesure soit suffisamment différente de la précédente. Surtout sur une LFP avec sa courbe de tension un peu plate (mais pas si plate que ça, comme on l'a vu)

 

Hypothèse: les petites oscillations dans le palier c'est les fluctuations du cumul du courant, et toutes les trois minutes c'est une nouvelle évaluation de la tension, puis une multiplication avec le cumul du courant. On remet le compteur du cumul de l'intensité a 0, et c'est reparti pour un palier... Mais ça explique pas pourquoi les oscillations sont que tout les 4 paliers

 

Autre hypothèse, c'est l'inverse: les oscillations sont dû a la tensions instantanée, et toutes les trois minutes on multiplie  la dernière tension mesurée (ou la moyenne?) Avec le cumul en Ah.

 

Il faudrait que j'affiche en même temps les relevés de la tension et du courant pour bien faire

 

Autre hypothèse, la courbe de charge est connu, et découpé en petit morceaux, et toutes les temps de temps, il y a un recalage

 

Autrement dit il y a une table de mapping entre la tension et les kWH:

(Exemple de valeurs au pif)

45.25kWh, c'est entre 300 et 302V

45.5kWh, c'est entre 302 et 303V

...

 

Pas de prise en compte de l'intensité dans cette hypothèse

 

Les oscillations arriveraient si on est entre deux valeur, ici 302.001, 301.99, 302.002, 301.99 etc....

 

Bref, beaucoup d'hypothèses, mais je voulais déjà dire que:

- faire l'intégration de la tension x l'intensité par le temps ne peux pas expliquer des diminutions de kWh dans un palier

- les oscillations se font toutes les 4 paliers comme si on retombait sur une valeur remarquable 

- je ne vois pas de raison d'attendre 3 minutes a moins de mesurer une valeur physique qui bouge peu avec le temps

 

 

Je vous livre ça en l'état, je vais essayé de superposer la courbe de tension et d'intensité dessus pour voir...

 

 

[Jboll]

Le 01/06/2023 à 23:55, MrFurieux a dit :

Si le BMS fait le même calcul avec des entiers 64 bits il n'aura pas ce problème, vu que pour ce type d'addition le résultat serait exact avec des entiers.

Je crois comprendre ce que tu dit, tu veux dire que le BMS utiliserait des  valeurs entières a la place des nombre a virgule. Donc pas de calcul de "double" mais de "long". Ça voudrait dire qu'il a la valeur de la tension en mV (admettons) et qu'il aura la valeur, par exemple, de 312455mV qu'il multipliaient avec une valeur en mA,  comme par exemple 12000 mA. Et la multiplication tient dans 64 bits. C'est sans doute vrai. Mais tu risque d'avoir un problème avec le compteur qui va vite monter. Ça se tente, je peux essayer pour voir...

[Jboll]

Le 01/06/2023 à 19:20, MrFurieux a dit :

Les graphiques que tu postes annoncent des variations de capacité qui dépassent 30% entre charge lente et rapide, le contraste est amusant avec les tests de @Jboll qui essaie d'expliquer 0,5% de différence de capacité en supposant implicitement que la méthode de charge n'a pas tellement d'influence

J'ai justement fait une recharge a basse puissance pour être sûr d'en mettre un max

 

Bien que effectivement je pense que ça joue pas vraiment, car le cas d'une  recharge rapide a puissance constante n'existe pas : sur un SUC par exemple, la puissance va varier au cours de la charge, diminuant petit a petit jusqu'à l'arrêt, on est pas a courant constant.

Et cette diminution de la puissance va pouvoir en mettre plus donc... Si on voit pas de différence sur un SUC, c'est, je pense, parceque la puissance de charge n'est pas constante. A la différence des courbes que montre @LIION

[Jboll]

Le 02/06/2023 à 00:24, Jboll a dit :

Je crois comprendre ce que tu dit, tu veux dire que le BMS utiliserait des  valeurs entières a la place des nombre a virgule. Donc pas de calcul de "double" mais de "long". Ça voudrait dire qu'il a la valeur de la tension en mV (admettons) et qu'il aura la valeur, par exemple, de 312455mV qu'il multipliaient avec une valeur en mA,  comme par exemple 12000 mA. Et la multiplication tient dans 64 bits. C'est sans doute vrai. Mais tu risque d'avoir un problème avec le compteur qui va vite monter. Ça se tente, je peux essayer pour voir...

En y réfléchissant un peu plus, je me demande si ce serait pas ça la raison des paliers: d'avoir un compteur de grand nombre d'un côté, et au bout d'un moment, ou d'une certaine valeur trop grande, de faire la division puis de mettre cette valeur dans une variable accumulateur ayant un nombre plus petit.

C'est a dire: dans un palier ils se basent en mA et en mV sur des entiers, puis au moment de le mettre dans le cumul des kWh ils ne font la division que toutes les 3 minutes. 

Au niveau précision c'est peut-être même encore mieux!

(Par contre ça n'explique pas les oscillations a l'intérieur d'un palier)

[Jboll]

Le 02/06/2023 à 00:14, Jboll a dit :

Je vous livre ça en l'état, je vais essayé de superposer la courbe de tension et d'intensité dessus pour voir...

Bon, c'est pas probant, 

Tension :

Courant 

Courant smooth 

 

Je vois pas de corrélations 😕, surtout comparé à un palier sans oscillation :

Tension

Courant

 

Le pire c'est un zoom lors d'une descente d'une oscillation, la tension monte et le courant également, donc aucune raison que le remaining en kWh diminue

Tension :

Courant

 

Encore plus zoomé :

 

 

Bon, la cause des oscillations m'échappe, tant pis

 

Modifié juin 2, 2023 par Jboll

[Jboll]

@MrFurieux, tu me demandais si le remaining diminuait lorsque la voiture est en stationnement prolongé

 

Durant une nuit, j'ai laissé mon sniffeur tourner, il a enregistré la fin de la charge à 6h du matin, ainsi que l'arrêt du bus can vers 6h15 avec un remaining de 51.5 kWh

Puis veille de la voiture jusqu'à 8h30

Lors du réveil, le remaining n'est "plus que" de 51.38 kWh. Elle s'est donc réveillé avec moins d'énergie

Donc la voiture perd du remaining pendant son stationnment

 

 

Dodo:

 

réveil :

 

 

 

 

 

[Jboll]

@planetaire, tu me disais que le critère d'arrêt de la charge ne pouvait pas être la tension des cellules car envoyé toutes les minutes, tu trouvais ça trop risqué. Et qu'il devrait y avoir un message spécifique qui indique la tension min/max des cellules envoyé plus souvent

 

J'ai cherché un autre message, et j'ai trouvé celui-ci:

 

J'ai fais deux essais, et je continuerai ces prochains jours, mais pour l'instant ça tient très bien :

Première recharge arrêtée dès qu'une cellule a atteint 3.802 V

 

Seconde recharge le lendemain, exactement la même valeur  :

 

Je vais continuer quelques jours encore pour voir si ça se confirme

 

Bon par contre la spec CATL indique 3.7 V maximum... 🤐

 

Et 3.7 v c'est là :

 

Pour rappel :

 

 

[tben]

Le 01/06/2023 à 12:36, Jboll a dit :

51,26 et 51,24

 

Le 01/06/2023 à 12:36, Jboll a dit :

Et j'aimerai savoir si certains d'entre vous, avez une idée de pourquoi ça oscille comme ça pendant cette dernière charge ?

Le 01/06/2023 à 12:36, Jboll a dit :

@tben m'a plusieurs fois dit que ça marche par palier, ok ici le palier serait de 0.02 kWh

Cela oscille sur certaines valeurs. J'ai très souvent le phénomène. Si tu regardes toutes tes données et pas qu'à 100% du Remaining, tu verras que la valeur varie par incrément de 0.12 3 fois sur 4 et 0.14 une fois sur 4. Cela permet de faire 0.5 toutes les 4 valeurs. Et le 0.14 est parfois hésitant avec le 0.12, mais ce sera à la fin un 0.14. Tu tombes dans ce cas de figure, sauf que sur le NFP tu ne sais pas où tu en ais sur ce cycle de 4 incréments.

Modifié juin 2, 2023 par tben

[tben]

Le 01/06/2023 à 23:14, Jboll a dit :

faire l'intégration de la tension x l'intensité par le temps ne peux pas expliquer des diminutions de kWh dans un palier

Exact.

[tben]

Le 01/06/2023 à 23:14, Jboll a dit :

les oscillations se font toutes les 4 paliers comme si on retombait sur une valeur remarquable 

0.5 = 0.12 + 0.12 + 0.12 + 0.14

Et comme le 0.14 est bizarre, il hésite avec 0.12, mais cela sera un 0.14.

Modifié juin 2, 2023 par tben

[Jboll]

Le 02/06/2023 à 18:25, tben a dit :

0.5 = 0.12 + 0.12 + 0.12 + 0.14

bien vu 👍 

 

[tben]

Le 01/06/2023 à 23:14, Jboll a dit :

attendre 3 minutes

regarde lors de ta charge rapide, ou en conduite, ce n'est pas 3 min, c'est quand il atteind un seuil. Et le seuil n'est pas le même en montée ou en descente, mais un 12 restera un 12 en montée ou en descente et pareil pour le 14. Ce 14 est d'ailleurs une vraie plaie. Je laisse Jboll le découvrir.

[tben]

Le 02/06/2023 à 15:08, Jboll a dit :

J'ai cherché un autre message, et j'ai trouvé celui-ci:

J'ai longtemps pensé qu'il servait à rien et qu'il n'était que la conséquence des autres valeurs individuelles.  J'ai réussi à bricker mon canserver en voulant les enregistrer. Trop de variables manipulées. Heureusement je suis devenu un pro du recovery. Je vais devoir choisir en attendant une nouvelle version du microcode.

Il nous faut vérifier que ce pid nous permet d'avoir des données plus fréquentes et pas un résumé de l'autre pid.

Je n'ai pas réussi à vérifier ce point avant de partir.