Reprise du message précédent :

 
Ouais ça a l'air tout con. Je suis parti sur du polymère histoire d'avoir un truc un peu mieux. J'ai repris les valeurs/tensions, pris du Nichicon, ça vous semble correct?  Je suis entre 5 et 8 mOhms en ESR.
https://pics.fl0w.fr/images/2024/10 [...] 181747.png

KZG correspond à priori à une série faible ESR chez Chemi-con, exemple datasheet.
 
Le fabricant n'indique pas explicitement l'ESR max mais la tan δ pour une tension nominale donnée. Il convient de sortir la calculatrice :
 
ESR max = tan δ /(2.Π.f.C). La fréquence f est donnée dans l'exemple à 120 Hz.

Je regardais sur un forum les références conseillées pour remplacer les KZG, en gros il est conseillé de partir sur 0.007ohm à 0.012ohm donc je suis dans les clous: https://www.mouser.fr/ProductDetail/647-RL80J821MDN1KX
Pour les autres en revanche je manque d'infos... D'après l'aspect visuel ce serait des Fujitsu avant leur revente à Nichicon.

Je sais pas trop pourquoi vous vous prenez la tête avec l'ESR, si c'est bien fait, il des MLCC qui ont un faible ESR pour compenser.

Bon j'ai quand même tenté de poser la question sur le forum badcaps, ils ont l'habitude avec le recap de matériel informatique. Je préfère éviter de faire une connerie et cramer la carte

Oui et non .

TL; DR:
Quand on découple, on veut lisser la tension au voisinage de ce qui consomme du jus, et au voisinage de ce qui fournit le jus pour ne pas avoir trop de courant AC sur les pistes/fils qui feraient antenne. Ça impose de filtrer aux fréquences d'horloge et leurs harmoniques/sous-harmoniques (>1MHz), et aux fréquences de découpage de l'alim (50k~5MHz), mais on a aussi des fréquences plus faibles à filtrer, comme l'économie d'énergie, le rafraichissement de l'écran, le scheduler de l'OS (qui vont potentiellement faire varier la consommation à intervalles réguliers, 10Hz~1kHz).

Ça serait parfait si on pouvait placer 1'000uF avec 1uOhm d'ESR et aucun ESL sur le die du GPU, mais ça ne rentre pas.
À la place, on va mettre plein de capas MIM/MOM de ~10pF un peu partout sur le die, éventuellement 100pF~1nF là où il y a de la place sur le die, puis des petites capas MLCC en boitier minuscule le plus proche des billes d'alim, sur un interposer ou sur le PCB, parfois de 100pF~1uF, et des capas MLCC plus grosses plus loin, jusqu'à des grosses capas chimiques là où il y a de la place.

La courbe d'impédance d'un réseau de filtrage donne à peu près ça sur le PCB, quand on met tout en parallèle, et qu'on prend en compte l'ESR et l'ESL (y-compris celle des pistes), en plus de la capacité de chaque capa :

Le premier souci à avoir un ESR trop élevé sur des capas chimiques, c'est que la courbe rouge va être décalée vers le haut. Effectivement, ça n'est pas gênant, vu qu'il n'y a pas grand chose de critique à filtrer à ces fréquences.

Le second souci, c'est que ces capas sont traversées par pas mal de courant d'ondulation. Si l'ESR augmente, ESR*I² augmente aussi, et la capa chauffe, ce qui dégrade encore plus son ESR, et limite sa durée de vie.
C'est la raison la plus importante pour le choix de capas low-ESR dans des VRMs .

La magie noire et autres magouilles de PLL/horloges diverses (y-compris les VRMs) qui rajoutent des modulations spread-spectrum permettent de varier légèrement la fréquence, et d'étaler les pics dans le domaine fréquentiel, ce qui est plus facile à filtrer.

 
Merci mais je fais des cartes numériques avec des FPGA et autres chips qui consomment un peu avec design d'alim à découpage multi-phase. Je ne suis pas expert en alim mais le découplage je m'y connais un peu.
 
Toutes tes explications sont valides, mais tu oublie un point important : les plans d'alims.
L'emplacement des capas chimique en sortie des DC/DC et assez loin du GPU ça montre juste que ce sont des capa réservoirs sans véritable objectif de découplage : que ce soit leur ESR (quelqu'il soit) ou l'ESR/ESL équivalent du plan d'alimentation, leur efficacité ne sera pas très élevée passé les quelques MHz.
 
D'autre part le package importe beaucoup dans l'ESR et l'ESL. Et les pins traversantes par rapport à du CMS ça n'a rien à voir. On a pas la photo du bottom de la carte mais je pense qu'il y a de nombreuses capas de découplage MLCC.
 
La capa de faible valeur (genre 100nF) sous une capa chimique c'est pas un bricolage, ça permet réellement de limiter les ondulations de certaines fréquences. Mais utiliser une capa traversante chimique de nos jours c'est plutôt ça le bricolage en fait. Bon là le PCB est assez ancien donc il faut faire avec.
 
 

 
Tu te concentres sur le découplage du côté de ce qui consomme, sans regarder l'alim qu'il faut aussi découpler à son entrée et filtrer à sa sortie.
 
Sans ça, tu te retrouves avec beaucoup de courant AC dans les pistes et fils (et aussi les plans ) d'alim, qui vont rayonner parce que leur impédance n'est pas nulle.
 
C'est exact, les capas chimiques sont toutes à droite du PCB, là où est l'alim.
On y voit des capas à l'entrée de l'alim (on devine un LC proche du connecteur Molex et sans MOS à côté) qui servent à découpler localement l'alim pour compenser l'impédance du câble en amont du connecteur Molex. Ce n'est pas le plus critique si l'alim a un bon PSRR, mais c'est loin d'être une broutille. Si cette capa a une impédance trop élevée à la fréquence où on en a besoin, alors du courant AC traverse le câble d'alim, et rayonne du bruit.
 
Pareil avec les capas chimiques en sortie d'alim. Il y a forcément des capas MLCC autour pour filtrer les harmoniques de la fréquence de découpage. Mais les capas chimiques filtrent les signaux à des fréquences plus basses, dont potentiellement la fréquence de découpage. Vu la techno d'alim (MOS discrets, "grosses" selfs), il y a des chances que la fréquence de découpage soit relativement faible (100~200kHz), et que les grosses capas soient vraiment nécessaires.
Le layout respecte les bonnes pratiques avec une boucle entre les deux MOSFETS, la self et les capas qui est la plus courte possible, pour éviter de trop rayonner.
 
Le fait que les capas chimiques en boitier traversant aient un ESL énorme comparé à celui de capas 01005 est la raison pour laquelle on doit mettre des capas avec une fréquence de résonnance différente en parallèle (voir la première figure de mon post précédent ).
 
Un des soucis de l'ESR, aussi bien trop élevé que trop faible, c'est que ça va bouger un pôle qui affecte la boucle de régulation de l'alim : https://www.edn.com/voltage-mode-co [...] egulators/
 

 
Je ne parlais pas de design, mais réellement de bricolage pour réparer un circuit avec des composants usés, ou l'améliorer s'il a été mal conçu .

Bon, j'ai avancé sur aucun projet perso, mais j'en ai un nouveau en tête. J'ai pas le nom, j'y ai joué l'autre jour et c'est plutot marrant.
Cela ressemble un peu au jeu ou il y a des tetes qui sortent et il faut taper dessus avec un marteau, mais les tetes sont remplacés par des gros boutons qui s'allument et cela se joue à deux en face à face. Celui qui fait le meilleur score dans un temps imparti a gagné.
Rien de bien compliqué à faire, mais il y a 9 boutons par joueurs ... non mais vous y croivez vous ?
Je pensais m'orienter vers un MCP23S17 (MCP23017 en SPI) mais forcément, il n'y a que 2x8 ports. De tête, vous avez une ref qui fait 2x16 ports, (optionnel : avec gestion d'interruptions sur tous les ports vers 1 interruption) ? J'ai besoin d'une entrée pour la detection du bouton et d'une sortie pour allumée le bouton.
Pareil, j'ai besoin d'un mosfet sur la tranche autour de 3.3v ou 5v pour l'alimentation des LED en 5v, 1A max, si vous avez une ref en tête ^^
 
Merikiii

Ca je connais
Tu veux utiliser quel AVR/Arduino? Pour tes IO tu fous des 74HC165 et 74HC595 sur le SPI et tu fais du polling. Largement suffisant et bien moins cher que les MCP (qui sont pas mauvais du tout mais me paraîssent bien trop "gros" pour cette histoire).
Pour ton MOSFET, au pif AO3401/2 (P/N) mais c'est du CMS et faut revérifier Vgsth.

C'est l'enfer, j'ai dépensé "pleins" de sous mais comme je suis pas chez moi ... je peux juste regarder le stock s'accumuler
 
Braif
 
Je connaissais pas, si j'ai bien compris, le 74HC165  c'est en entrée et le 74HC595 en sortie ? Tu mets une clock et tu lis les entrées 1 par 1, bon cela oblige toujours à en avoir 2x joueurs mais c'est une bonne idée.
Les arduinos vont etre trop lent à mon avis, sur la borne tu as pas mal d'interface, en plus des 2x 9 boutons (autant en mettre plus tant qu'à faire), il y a 2 afficheurs de score + 2 trucs gadgets d'indicateur de temps.
 
Je pensais utilisé un ESP32 qui a 2 core avec 1 pour le score/gadgets et 1 pour la lecture des boutons. En meme temps j'ai envie de m investir dans les STM32 pour me faire la main, mais j'ai pas encore regardé le cout en 2 core.
Les ESP8266 n'ont qu'un core de mémoire.
A moins que l'I2C ne puisse se faire en tache de fond, mais j'ai un gros doute.
 
Merki

Exact, le '165 pour les entrées et le '595 pour les sorties. Le AVR va s'ennuyer, c'est largement suffisant, à condition de ne pas coder avec les pieds.
 
Attention avec les '165 et les '595, on peut en mettre plusieurs et les deux variantes en "daisy-chain" sur un port SPI mais faut s'y prendre correctement. Internet devrait pouvoir te renseigner.

J'allais dire qu'il suffit d'un µC 8 bits avec suffisamment de broches pour tout faire sans s'emmerder avec d'autres circuits intégré mais je crois qu'il faudrait surtout commencer par te palucher la lecture d'une de leur documentation et que tu te fasses la main avec des petits exemples parce que là, je crois que le problème n'est pas tant matériel que logiciel...
Ton truc, c'est ce que mon maitre de stage d'IUT m'avait demander de faire le premier jour où je suis arrivé pour me jauger : câbler des boutons, faire clignoter des DEL et envoyer de la grouille en I²C sur un afficheur

Non mais là même un 8051 aurait le temps de faire le café en plus de gérer le jeu tellement c'est peu exigent en ressources.
 
Tip: pars sur un machin qui permet d'avoir FreeRTOS, ça facilite énormément le travail pour coder n'importe quel truc, y compris un simple clignotant de LED

Faut je vois si avec le reste du bordel, la reactivité reste là. J'avoue j'ai pas calculé, j'utilise quasiment que des attiny  
Mais je ne pense pas que l'arduino suffise, le projet final, c'est pas uniquement le pilotage de 18 boutons

Si tu veux des renseignements faudrait penser à nous donner toutes les infos utiles...
 
Sinon faut aussi voir comment on code, Arduino, pur C avec les pieds, pur C digne de ce nom, ...

Je rage un peu là.  
 
La buse de mon fer à dessouder s'est bouché en pleine session quand j'allais attaquer un condensateurs entre deux plans et je ne m'en suis pas rendu compte. Je me suis retrouvé à surchauffer la pastille qui s'est délaminée et arrachée du via (le plan était sur l'autre face).
Je suis blasé.

 
C'est la merde, mais tout n'est pas perdu .
 
Si l'intérieur du via n'est pas endommagé et rempli d'étain ou avec encore la patte du composant que tu peux couper, le contact est raisonnable et tu peux ressouder un fil entre la pastille arrachée et les pistes déconnectées.
Ensuite, tu peux gratter le vernis des plans de l'autre côté et y mettre une capa équivalente en boitier SMT. Bon courage .
 
Si le PCB est délaminé ou que l'intérieur du via dépasse d'un côté, c'est un souci plus sérieux .

 
C'est effectivement sauvable. Il y a encore le via et je pense pouvoir braser dedans. Je vais charger en flux la pastille côté composants, avec un peu de bol l'alliage viendra par capillarité jusque là et j'aurai un contact aussi bon qu'à l'origine.
Et, au pire, il y a un autre condensateur à côté donc je peux me repiquer dessus.
Mais j'ai bien ragé quand la pastille est restée collée à la buse.

Pour l'instant c'est le debut Pour que ce soit rigolo, faut du son, des animations, des bloup bloup et des blips blips
Les prix sont au final les même, le seul interet pour moi de l'arduino et du STM32 c'est qu'ils sont en 5v là où l'ESP est en 3.3v ce qui est relou

C'est ça le truc que je veux copier en plus petit
https://m.youtube.com/watch?v=VSci73xNhN0

A oui ben là je pense qu'il faut un Arduino pour les boutons, un stm32 pour l'affichage et un raspi 4 pour générer le fond 3d temps réel à projeter en arrière plan

Ou alors tu prends une planche en bois une quinzaine de bout de mousse et tu développes le jeu en VR