Gestion de charge batterie lithium

[davidif]

Bonjour,

Il semblerai que la carte de démo réponde bien, sur mon proto la charge ce passe plutôt bien malgré tout, juste ce léger bruit m'interroge et notamment lorsque je déconnecte la batterie alors que le DCIN est encore présent ou là le bruit s'accentue jusqu'au moment ou je coupe le DCIN.

Voici une photo sur la démo et le proto, je charge à 3A, 29,4V et un DCIN à 34Vdc

Démo
Demo3.jpg
Demo4.jpg

Proto
PROTO3.jpg
PROTO2.jpg

Comme dis, j'ai gardé les mêmes valeurs et réf fabricant des composants, sauf pour ceux intervenant dans les caractéristiques de charge souhaitez en courant/tension, également les condensateurs dont j'ai changé les tensions plus élever.
au niveau routage de fréquent plan on été fait sur le chemin de charge, ainsi que des via pour que circule le courant entre chaque plan.

Auriez vous une suggestion
Merci
-----

[invitead6c50a3]

Sans voir ta carte proto difficile de se faire une idée.
Le routage, comme je te l'avais déjà dit, est une des difficultés pour les non initiés.
Le fait que tu aies un "bruit" audible à vide semble indiquer que tu as peut être des déclenchements ignorés ce qui donnent des regroupements d'impulsions avec des trous plus ou moins réguliers (pulse bunching), ça arrive lorsque le courant devient trop faible.
Tu devrais pouvoir le voir à l'oscilloscope.

Ca donne quelque chose qui ressemble à ça:

[davidif]

Bonsoir Exotique, ok mais je ne peux pas zoomer sur ton image pour mieux voir, et à ton avis ou pourrais-je agir pour palier à ce problème sur mon proto.

[invitead6c50a3]

Poste une photo de ta carte et rappelle moi la ref de ton circuit de charge, j'ai un peu perdu le fil

[davidif]

Bonjour,

j'utilise le LTC4013

Qui globalement fonctionne plutôt bien, les 4 chargeurs suivent un processus de charge correct, juste ce bourdonnement qui s’accroît quand le courant diminue et notamment lorsque je déconnecte la batterie avant d'éteindre le dcin en fin de charge.

20201220_130643.jpg
20201220_130718.jpg
20201220_130757.jpg
20201220_130940.jpg

[davidif]

Au début, c'est vraiment léger, il faut tendre l'oreille proche du circuit, il semblerai focaliser vers la self, parfois à peine perceptible mais augment à un courant faible voir inexistant en fin de charge.

[davidif]

j'échange actuellement avec le support du constructeur qui m'a demander notamment d'aller voir du côté de ISMON, j'ai donc pris des photos du signal à différente étape de charge et lorsque je débranche la batteries.

Là je suis à 3A valeur initialement calculé pour ma charge, le signal est stable
3.04A v0.jpg

à 2A, l'instabilité débute
2A.jpg

à 1.5A
1.55A.jpg

Puis lorsque je débranche ma batterie
Batterie débranché .jpg
Avec bruit plus prononcer

j'étains donc le DCIN, puis rallume et plus rien, je peux recharger de nouveau.
Au pire je peux gérer la fin en inhibant le dcin du chargeur en fin de charge par la commande sur l'enable, mis à zéro via un transistor commandé par mon micro, mais ce serait mieux que je trouve la solution.

[invitead6c50a3]

Selon moi tu as des imperfections liées à ton routage.
Par exemple ça (les pistes que j'ai mis en rouge):

[invitead6c50a3]

Elles sont beaucoup trop longues.
Sur ce type de routage il faut commencer par router les pistes les plus sensibles en priorité sur toutes autres considérations.
Si tu compares par rapport à la carte d'évaluation tu verras que tous les signaux rapides et à fort di/dt sont au plus court.
Il faut impérativement que la pin 2 soit découplée au plus près du LTC4013 et PGND (pin26) doit être prise au plus près (ton via est loin et la piste est bien trop fine).

[invitead6c50a3]

Il sera très difficile de solutionner à 100% en l'état de ton routage actuel, au mieux tu peux minimiser ce bruit mais pas l'éliminer complètement.
Une astuce que tu peux tester:

tu prends un carré de cuivre légèrement débordant de ton LTC4013 que tu poses avec un petit scotch double face, il va te servir de plan de masse.
Tu soudes sur ce carré de cuivre un L assez large en cuivre aussi que tu raccordes au GND de puissance (par exemple sous ton MOS à droite de R19 en grattant le vernis avec un cutter)
Puis tu soudes une capa de découplage de 100nF X7R que tu montes perpendiculairement au plus près de la pin2.
Idem avec les pins 27 et 28 avec un 1µF X7R.
Puis tu relies pin 26 à ce plan de cuivre GND puissance et tu coupes ce fil de masse qui part de pin26.
Ca ne peut qu'améliorer la situation.
Vérifie également que tous les retours faibles signaux du LTC4013 partagent le même GND signal, ils ne doivent pas partager le GND de puissance .

Tu verras sur le doc de la carte d'éval:
https://www.analog.com/media/en/dsp-...ls/DC2374B.pdf

il est clairement indiqué sur les GND la lettre "S" qui indique le GND signal, vérifie que c'est bien le cas des composants de ton routage.

[davidif]

Merci pour tes conseil Exotique, j'ai effectivement rapproché les condos de découplage comme tu peux le voir sur mes dernières photo, j'ai privilégié les pistes en puissance mais le dcin qui va en 2 n'est pas de la puissance ni du signal rapide sauf erreur.
sur la carte de dev, il est plus facile de mettre tout à proximité avec du 0402 là ou j'ai préféré mettre du 0805 et donc n'étant pas sûr de pouvoir tout placer lors du routage je n'ai pas tout collé au LTC.

Je n'ai pas encore fait l'essai, mais avant je préfère te poser la question or dans la mesure ou mes batteries sont censées faire du hot swap donc pas forcement présente sur tout les canaux je me posais la question de conditionner le enable du chargeur sur la présence ou non de la tension batterie et non le dcin ?... comme ça je pali au problème d'extraction de la batterie de l’emballement, dcin toujours présent le chargeur est validé lorsque la batterie est présente, qu'en penses tu ?

[invitead6c50a3]

DCIN alimente la pompe de charge des MOS, cette capa doit être référencée au GND de puissance.
En mode mise au point privilégie des boitiers type 0805 ou mieux des 1206, plus pratique à manipuler et placer.
En principe le fait d'enlever la batterie à chaud ne doit pas être un problème mais tu peux activer/désactiver par le Enable c'est toujours plus propre de faire comme ça et tu pourras limiter aussi ta consommation à vide si la batterie n'est pas branchée.

[davidif]

Bon bah, l'expérience n'est pas concluante du coup.

J'ai bien remplacer dcin par le vbat en enable mais le résultat est le même en fait, car la batterie débranché j'ai toujours une tension de 29V de présent en sortie chargeur donc le enable est toujours actif.
Je dois trouver un autre moyen si je n'arrive pas à résoudre directement le problème dû au routage.

[invitead6c50a3]

Si tu mets la pin ENAB à 0 (avec un petit MOS par exemple commandé par ton µC) tu mettras le chargeur OFF.

[davidif]

Si tu mets la pin ENAB à 0 (avec un petit MOS par exemple commandé par ton µC) tu mettras le chargeur OFF.

Oui, ça sa fonctionne bien, c'est ce que j'ai fais sur mon proto pour gérer les charges, un simple NPN commandé par mon micro qui met l'enable à "0", c'est OK mais je pensais qu'en plus si je remplaçai le branchement du DCIN sur enable par le Vbat je pouvais palier à mon problème de routage qui rend instable le chargeur lors de l'extraction de la batterie en attendant de trouver la cause, mais c'est à priori pas possible car la sortie du chargeur ne chute pas lors de l'extraction et reste autour de 29V.

[davidif]

Je peux aussi récupérer les infos des status de chaque chargeur sur mon micro, ce qui va m'aider à palier ce problème en fin de charge par exemple il me suffira de désactiver temporairement les chargeurs, aussi si j'arrive à échanger avec le max17205 (ce qui n'est toujours pas le cas et j'échange avec le support maxim les informations instantanés me permettra d'avoir une meilleur gestion.

[davidif]

Bonjour,

En ré-examinant mes capa, si j'ai pris les mêmes valeurs, j'ai modifier leur tensions mais aussi je n'ai pas spécifié les techno au câbleur qui à approvisionné les composants, ce pourrait-il que ce soit lié ?

[invitead6c50a3]

Le X7S a une tolérance un peu plus grande que le X5R de la carte d'éval mais ça n'explique pas ton problème.

[davidif]

Le X7S a une tolérance un peu plus grande que le X5R de la carte d'éval mais ça n'explique pas ton problème.

Bonjour, toujours dans quête de résoudre mon problème d'instabilité, bien qu'une grande partie serait causé par mon routage je sais que dans un système électronique de ce genre la stabilité réside dans l'équilibre self condensateur et résistance également, bien qu'ayant respecté toutes ces valeurs je me demandais si l'ajout du trimer au niveau du Vfb ne serait pas perturbant ? car plus ou moins selfic de par l'enroulement non ?....

20201220_130940.jpg
chargeur.jpg

[davidif]

Bonjour,

Au sujet de mon problème toujours pas résolu, malgré la grande cause du routage, est-ce que le circuit en aval ne serait pas en cause par exemple ?

Circuit chargeur_alime.jpg

Je ferai bien le test mais difficile à faire car tout est sur un même plan ou les composants compliqué à dessouder dessus car il faut chauffer beaucoup et je ne veux pas détériorer des composants aux environs, .... je vois comment faire.
Aussi j'ai tenté d'isoler le chargeur du reste en fermant le mosfet M4 après la batterie, mais j'ai eu des pics bizzares sur le drain lors de l'extraction de la batterie

20201223_181935.jpg

Là quand je laisse ouvert le mosfet M4

20201223_182340.jpg

si j'arrive à échanger avec le max17205, je pourrais palier au problème en le contournant, mais pour le moment il ne veux toujours pas causer avec moi (: malgré mes nombreux essais en comparant avec la carte de dev direct avec le pc.

Merci pour tes infos et bonne fêtes

[davidif]

Bonjour,

j'avance bien sur mon proto, la com ce fait correctement après avoir fait quelques actions correctif sur la protection des port I2C notamment en plaçant des diodes de transil 3,3V à priori ça à l'aire de tenir.

Je li les registres de soc, courant, tension, je n'ai pas encore réussi à écrire mais pour le moment j'ai détourné le problème en chargeant la configure directement sur pc et l'adaptateur USB.

Une question ce pose, lorsque je connect mes batteries à chaud, globalement ça ce passe plutôt bien malgré quelques détails.

pour éviter d'avoir d'éventuels étincelles en plaçant la batterie à chaud, l'ordre serait de connecter la borne + puis la masse, or la logique de connection d'un périphérique serait d'abord la masse puis le + ensuite la com.

que me conseillez vous ?
Merci

[invitead6c50a3]

Mon conseil serait de faire une détection d'insertion de la batterie, c'est ce qui est fait habituellement.
Par exemple en disposant un petit aimant sur ta batterie et de l'autre coté un capteur de ce type de chez Honeywell très peu gourmand en courant (famille SL353) :

http://www.farnell.com/datasheets/2012449.pdf

Le but est de réveiller par interruption à la détection et de ne rien consommer hors détection.

[davidif]

Mon conseil serait de faire une détection d'insertion de la batterie, c'est ce qui est fait habituellement.
Par exemple en disposant un petit aimant sur ta batterie et de l'autre coté un capteur de ce type de chez Honeywell très peu gourmand en courant (famille SL353) :

http://www.farnell.com/datasheets/2012449.pdf

Le but est de réveiller par interruption à la détection et de ne rien consommer hors détection.

Intéressant, si j'ai bien compris, ce composant ouvrirait le canal d'alimentation lorsque qu'un champ magnétique est détecté, je n'ai pas vu le courant max qui peut sortir par contre, sachant que je marge sur 10A max.

Oui effectivement j'avais pensé à une détection d'insertion par un simple contact en dessous des batteries notamment, ce qui pourrait me permettre de synchroniser plus efficacement mes canaux par la présence ou non des batteries.

Mais en y réfléchissant encore et encore (: ... j'ai placer des mosfet qui coupe le canal d'alimentation, piloté par mon micro et je détecte la présence des batteries en interrogeant les I2C, de la je peux ouvrir le canal mais faudrait-il encore qu'il n'y est pas de loupé sur la com quand je déconnecte et reconnecte, .... pour récupérer la com je dois redémarrer pour le moment ?... j'ai donc tenté de réinitialiser le port I2C concerné lorsque les valeurs en retour reste à "0" mais sans succès.

Merci pour tes solutions intéressantes

[invitead6c50a3]

Le but n'est pas qu'il alimente une commande de puissance mais d'envoyer une information sur une interruption qui sortira ton µC de son mode sleep ou d'acquitter l'insertion d'une batterie.
Il faut que tu construises un flowchart qui prend en compte l'insertion, puis la prise en compte, puis tu actives ce que tu souhaites dans un ordre sécurisé.

[davidif]

Le but n'est pas qu'il alimente une commande de puissance mais d'envoyer une information sur une interruption qui sortira ton µC de son mode sleep ou d'acquitter l'insertion d'une batterie.
Il faut que tu construises un flowchart qui prend en compte l'insertion, puis la prise en compte, puis tu actives ce que tu souhaites dans un ordre sécurisé.

OK je comprend,
Je peux aussi faire ma détection sur l'interrogation des port I2C, si j'arrive à les rendre fiable en hotswap (: ...

[invitead6c50a3]

Tu vas t'amuser un moment, l'I2C ne gère pas nativement les collisions il faut mettre en place des mécanismes de rattrapage et de gestion d'erreur sur le bus.

[davidif]

Tu vas t'amuser un moment, l'I2C ne gère pas nativement les collisions il faut mettre en place des mécanismes de rattrapage et de gestion d'erreur sur le bus.

sauf erreur, il n'y a peux voir pas de risque de collision sur mes bus, dans la mesure ou chacun des bus est sur un seul périphérique, et c'est un jeux de question réponse sur un même fil, ponctué par les ACK d'attente qui pourrait posé problème lors de mais changement à chaud.

[invitead6c50a3]

Oui on parle bien de la même chose
Les collisions sont pour les modes multi-maîtres, si tu n'en as pas la simple gestion des erreurs entre maître et esclave peut devenir un vrai casse-tête lors du rebranchement à chaud après une erreur.
Une erreur d'écriture par exemple peut avoir de lourdes conséquences sur un système batterie si aucun mécanisme de vérification n'est implanté.

[davidif]

Autre question, car j'ai un doute sur les valeurs lu du soc via le max17205

bien que celles ci paraissent toutes fois cohérentes, le soc baisse bizarrement pour le peut de conso sur des capacités batteries de 9000mA/H pour seulement alimenter mon microprocesseur car après charger certaines baissent de 3 à 4 % à environ 1h, tests vite fait ...

Je configure les batterie à l'aide de l'interface maxim "modelGauge m5 Fuel Gauge" et sa configuration wizard en 17 étape.
Ainsi j'ai listé les valeurs et adresse correspondante pour me préciser l'exactitude,



sont-elle correctes ?
Je m'interroge sur l'étape 2 notamment ou il est question de renseigner la charge termination current : je dois bien mettre 9000mA (capacité total de ma batterie)?
Ce n'est pas déduit des valeurs précédemment rentrées : 9000/7 = 1285 mA par cellules au nombres de 7 ?

De plus, j'ai tenté de refaire une configuration wizard en corrigeant des valeurs mais en dernière étape17 je n'ai plus la main sur l'option d'enregistrement en "write new conf" qui ce trouve grisé ? serais-la limitation en écriture ? j'ai cru comprendre que c'était limité à 7 en non volatile et une centaine ram ...

[davidif]

Bonjour,

Je m'interroge sur l'étape 2 notamment ou il est question de renseigner la charge termination current : je dois bien mettre 9000mA (capacité total de ma batterie)?
Ce n'est pas déduit des valeurs précédemment rentrées : 9000/7 = 1285 mA par cellules au nombres de 7 ?