diff --git a/Rapport/Rapport.typ b/Rapport/Rapport.typ index 100dcb1..ce14753 100644 --- a/Rapport/Rapport.typ +++ b/Rapport/Rapport.typ @@ -1,631 +1,626 @@ -= Projet de semestre CSH +#set text(lang: "fr") +#set par(justify: true) +#set heading(numbering: "1.") -= Lumière vidéo 200W bicolore +#let deux-images(a, b, legende) = figure( + grid( + columns: 2, + gutter: 2mm, + image(a, width: 100%), + image(b, width: 100%), + ), + caption: legende, +) -Ceci est le rapport de mon second projet PCB. +#align(center)[ + #text(size: 20pt, weight: "bold")[Projet de semestre CSH] -== Qu'est ce que c'est + #v(0.4em) -Je suis photographe en dehors des cours et un des outils qui est absolument indispensable en interieur c'est une ou plusieurs bonnes sources de lumière. + #text(size: 16pt, weight: "bold")[Lumière vidéo bicolore de 200 W] +] -Comme je ne fais pas que de la photo mais aussi de la vidéo, cette source de lumière doit être constante (donc pas un flash) et en général plus de puissance on a plus on est contents. +#v(1em) -Ca peut paraitre bizarre d'avoir des chiffres comme 100-200-500W pour des lampes, mais en photo et vidéo on utilise des diffuseurs de lumière pour avoir un rendu plus doux des ombres et cela réduit fortement l'intensité lumineuse effective et donc on a souvent besoin de beaucoup de puissance. +Ce rapport présente la conception, la fabrication et les tests d'une lumière vidéo bicolore de forte puissance. Il s'agit de mon second projet de PCB. L'objectif était de concevoir une source lumineuse portable, utilisable en photographie et en vidéo, avec une puissance nettement supérieure à celle d'une lampe continue de 100 W classique. -J'ai déja une lampe de 100W et clairement cela ne suffit pas et je suis obligé d'utiliser des "softbox" plus petites sinon c'est simplement inutilisable. Donc j'aurai vraiment un besoin de plus de watts. +== Présentation du projet -En plus de ca j'aurais besoin qu'elle soit portable car pour le moment je suis obligé d'utiliser une prise secteur pour ma lampe de 100W et c'est assez insupportable en plus de rendre une utilisation en exterieur virtuellement impossible. +Je pratique la photographie en dehors des cours. En intérieur, une ou plusieurs bonnes sources de lumière sont indispensables pour obtenir un rendu propre et contrôlé. Comme je fais aussi de la vidéo, cette source lumineuse doit être continue : un flash ne convient donc pas. -== Contraintes +En photographie et en vidéo, les puissances de 100 W, 200 W ou même 500 W peuvent paraître élevées, mais elles deviennent rapidement nécessaires lorsqu'on utilise des diffuseurs. Une softbox ou un diffuseur permet d'obtenir des ombres plus douces, mais réduit fortement l'intensité lumineuse réellement disponible sur le sujet. Il faut donc souvent beaucoup de puissance pour conserver une exposition correcte. -Pour que le projet rentre dans le cahier des charges du cours il faut implémenter : +Je possède déjà une lampe continue de 100 W, mais elle montre rapidement ses limites. Avec de grandes softbox, la lumière disponible devient insuffisante. Une puissance plus élevée est donc un vrai besoin pratique. -- Un MCU -- Une interface homme machine physique (boutons ecrans speakers etc.) -- Une commuication (I2C, SPI etc.) avec un capteur ou composant. +Un autre objectif important est la portabilité. Ma lampe actuelle doit être alimentée par le secteur, ce qui limite fortement son utilisation, en particulier en extérieur. Le projet vise donc à concevoir une lampe plus puissante, transportable et alimentée par batterie. -Dans notre cas, on ne devrait pas avoir de soucis à faire rentrer ces contraintes dans le projet. +== Contraintes du projet -Avec ce nouveau projet on a aussi plus de possibilités. *Si le projet les justifient* on peut par exemple : +Pour respecter le cahier des charges du cours, le projet doit intégrer les éléments suivants : -- Faire un PCB plus grand que 3x3 -- Utiliser autre chose que du FR-4 (ex alu pour la temperature) -- Utiliser des composants un peu plus marrants -- Utiliser 4 couches au lieu de 2 ++ un microcontrôleur ; ++ une interface homme-machine physique, par exemple des boutons, un écran ou des indicateurs lumineux ; ++ une communication avec un capteur ou un composant externe, par exemple en I2C ou en SPI. -(Possibilités à faire valider par les profs évidemment) +Ce projet se prête bien à ces contraintes. Le microcontrôleur est nécessaire pour piloter les LED, lire les commandes de l'utilisateur et communiquer avec le système de protection de la batterie. L'interface homme-machine sert à régler l'intensité et la température de couleur. La communication I2C est utilisée pour échanger avec le BMS. + +Ce second projet offre également plus de liberté que le premier. Si le projet le justifie, il est par exemple possible de : + ++ fabriquer un PCB plus grand que 3 cm × 3 cm ; ++ utiliser un autre substrat que le FR-4, par exemple de l'aluminium pour améliorer la dissipation thermique ; ++ utiliser des composants plus spécialisés ; ++ passer d'un PCB deux couches à un PCB quatre couches. + +Ces choix doivent évidemment être validés par les enseignants. == Choix des composants externes -=== Leds +=== LED -Mfr nbr: CTM-22-4018-90-36-TWD6-F3-3 +Mfr nbr : CTM-22-4018-90-36-TWD6-F3-3 +Mouser nbr : 896-CTM224189036TWD6 -Mouser nbr: 896-CTM224189036TWD6 +J'aurais idéalement voulu trouver une seule LED bicolore capable de fournir 200 W. Après recherche chez Mouser, Digi-Key et Conrad, je n'ai pas trouvé de composant correspondant exactement à ce besoin. -Ici j'aurais adoré pouvoir trouver une LED seule qui fasse bicolore et 200W. Maleureusement je n'ai pas trouvé de composants du genre sur mouser digikey ou conrad. - -Il faut donc se rabattre sur la seconde option : Utiliser une matrice de leds. - -Par chance il existe des leds plutôt puissantes qui tiennent sur leur propre PCB en aluminium comme par exemples celle la : +La solution retenue consiste donc à utiliser plusieurs modules LED. Il existe des LED de forte puissance montées directement sur un PCB en aluminium, ce qui facilite leur fixation sur un radiateur. #figure( image("/assets/LED.png", width: 50%), - caption: [Image prise de la datasheet avec mesures de la LED], + caption: [Image issue de la datasheet, avec les dimensions du module LED.], ) -Chaque pièce peut sortir jusqu'à 50W. 25W par canal de couleur. Pour contrôler la température il faut donc alimenter plus ou moins un canal par rapport à l'autre. +Chaque module peut fournir jusqu'à 50 W, répartis en deux canaux de 25 W : un canal chaud et un canal froid. La température de couleur est contrôlée en ajustant le courant envoyé dans chaque canal. -Il faut donc 4 leds pour arriver aux 200W. +Pour atteindre 200 W, il faut donc utiliser quatre modules LED. -Cette option est un peu moins bonne qu'utilise une seule led de 200W car cela prend plus de place et selon la distance avec le sujet on pourrait voir les 4 sources mais je pense que avec une telle puissance cela ne va pas se voir du tout. +Cette solution est moins compacte qu'une LED unique de 200 W. Elle occupe plus de place et, à courte distance, les quatre sources pourraient théoriquement devenir visibles. Cependant, compte tenu de la puissance et de l'utilisation prévue avec un diffuseur, cet effet devrait rester limité. === Refroidissement -Avec des LED aussi puissantes, la gestion de la chaleur est absolument critique. - -On va dimensionner le refroidissement en partant du principe que les leds convertissent 20% de l'énergie en lumière et 80% en chaleur ce qui est une estimation plutôt conservatrice. Cela veut dire qu'il faut dissiper environs 160W de chaleur tout en fardant les leds en dessous de 85 degrés qui est la valeur max recommandée dans la datsheet. +Avec des LED de cette puissance, la gestion thermique est un point critique du projet. -En partant du principe que notre circuit va fonctionner dans une température ambiante de 30 degrés celsius, notre budget est donc de 55 degrés. +Le refroidissement est dimensionné en supposant que les LED convertissent environ 20 % de l'énergie électrique en lumière et 80 % en chaleur. Pour une puissance électrique de 200 W, il faut donc dissiper environ 160 W sous forme de chaleur. L'objectif est de maintenir les LED sous 85 °C, qui correspond à la température maximale recommandée dans la datasheet. -Le RTH(ou Rθ) de nos leds est de 0.27 donc une montée de 13.5 degrés. L'epoxy thermique a un RTH de 0.1 donc 5 degrés. +En considérant une température ambiante de 30 °C, le budget thermique disponible est donc d'environ 55 °C. -Pour le radiateur on a donc le droit à 36 degrés de budget et donc 36.5 /160 = à peu près 0.22. +La résistance thermique des LED est de 0,27 °C/W. Pour 50 W par LED, cela correspond à une élévation de température d'environ 13,5 °C. L'époxy thermique ajoute environ 0,1 °C/W, soit environ 5 °C supplémentaires. Il reste donc environ 36 °C de budget thermique pour le radiateur. -Et en fait 0.22 de RTH pour un radiateur c'est très peu, en réalité des radiateurs passifs avec ce genre de resistances thermique ca n'existe pas vraiment (dans une taille raisonnable) donc il va falloir prévoir du refroidissement actif en plus. +Pour dissiper 160 W avec une élévation maximale d'environ 36 °C, le radiateur devrait avoir une résistance thermique proche de : + +$ 36 / 160 approx 0,22 $ °C/W + +Une résistance thermique de 0,22 °C/W est très faible. En pratique, un radiateur passif de taille raisonnable ne permet pas d'atteindre cette valeur. Un refroidissement actif est donc nécessaire. ==== Radiateur -Pour donner une idée, voici les deux radiateurs qui viennent avec les processeurs Intel et AMD. Ce sont ceux qui sont livrés avec les processeurs que l'on peut overclock et donc les plus puissants de leur gamme. +Pour se faire une idée des ordres de grandeur, on peut comparer ce besoin thermique avec des radiateurs de processeurs classiques. + +#deux-images("/assets/INTEL_rad.png", "/assets/AMD_rad.png", [Radiateurs de processeurs Intel et AMD.]) + +Le ventirad Intel présenté ici a un TDP de 65 W, tandis que l'option AMD atteint 140 W. Le TDP est une grandeur imparfaite, car il dépend du constructeur et des conditions de test, mais il permet tout de même d'avoir un ordre de grandeur. Avec environ 160 W à dissiper, le projet dépasse déjà les capacités de nombreux radiateurs de processeurs classiques. + +D'après les estimations faites pendant le projet, le radiateur Intel se situerait autour de 0,45 à 0,60 °C/W avec ventilation, tandis que le modèle AMD serait plutôt autour de 0,35 à 0,50 °C/W. Sans ventilateur, ces valeurs deviennent rapidement beaucoup trop élevées. + +Même avec un radiateur beaucoup plus performant, comme le modèle Noctua suivant, le résultat reste limite pour une lampe portable. #figure( - grid( - columns: 2, // 2 means 2 auto-sized columns - gutter: 2mm, // space between columns - image("/assets/INTEL_rad.png", width: 100%), - image("/assets/AMD_rad.png", width: 100%), - ), - caption: "radiateurs de processeurs intel et AMD" + image("/assets/Noctua_rad.png", width: 50%), + caption: [Radiateur Noctua réputé pour ses bonnes performances.], ) -Le ventirad Intel n'a un TDP que de 65W tandis que l'option AMD a un TDP de l'option AMD est de 140W. +Noctua indique que ce radiateur convient à des charges proches de 180 W. Sur le papier, cela pourrait convenir. En pratique, il est très volumineux, ce qui rend l'idée d'une lampe portable beaucoup moins réaliste. -Le TDP est une unité de mesure un peu bancale utilisée pour les radiateurs de CPU, mais déja on peut voir que avec nos 160W de leds on est au dela quoi qu'il arrive. +Un autre problème est la surface de contact. Les quatre LED occupent environ 60 mm × 60 mm, alors que la zone de contact du radiateur Noctua est plus proche de 38 mm × 40 mm. La surface à refroidir est donc nettement plus grande que celle prévue pour un processeur classique. -ChatGPT a estimé ces deux radiateurs entre 0.45 et 0.60 pour le intel et 0.35 à 0.5 pour l'option AMD et c'est avec un ventilo car sans on arrive vite dans les 1.7-2. +Il serait aussi possible d'utiliser un radiateur non prévu pour les CPU, ou même de concevoir une pièce sur mesure. Cependant, ces solutions sont généralement plus chères et plus volumineuses. Les radiateurs de CPU restent intéressants, car ils sont conçus pour évacuer beaucoup de chaleur depuis une petite surface, et ils sont disponibles à des prix raisonnables. -Et même si on va dans les radiateurs vraiment balèzes comme : +La piste la plus intéressante a finalement été celle des radiateurs de serveurs. Les processeurs de serveurs modernes ont une surface de contact plus grande que les CPU grand public. Cela correspond mieux à la surface occupée par les modules LED. + +Le modèle retenu est le Dynatron A51. + +Lien Digitec : https://www.digitec.ch/fr/s1/product/dynatron-a51-refroidisseur-cpu-1u-pour-socket-sp6-passif-27-mm-ventirad-processeur-39319613 #figure( - image("/assets/Noctua_rad.png", width:50%), - caption: [Radiateur Noctua réputé pour être très performant], + image("/assets/radiateur.png", width: 50%), + caption: [Dynatron A51.], ) -Noctua nous indique qu'il est adapté à une charge dans les 180W. Ce qui en théorie nous irait mais c'est déja à la limite et il est absolument immense ce qui rend l'idée de faire une lampe portable ridicule... +Il s'agit d'un radiateur en cuivre prévu pour des serveurs 1U. Il est moins volumineux que les radiateurs de CPU classiques très performants, tout en annonçant un TDP de 200 W. Avec une ventilation adaptée, il devrait donc être suffisant pour ce projet. -En plus de cela, la surface que les leds représentent est de environs 60x60mm ce qui est beaucoup plus grand que les 38x40mm que propose l'option Noctua. - -Alors on pourrait aussi ne pas utiliser un radiateur de processeur. Il existe pleins d'options qui pourraient peut-être nous aller ou on pourrait même le faire nous même. Cependant, ces options sont beaucoup plus onéreuses et souvent plus volumineuses. L'objectif de refroidir des choses plutôt petites et plates qui chauffent beaucoup est typiquement la raison d'être des radiateurs de CPU et il en existe tellement que les prix sont beaucoup plus intéressants. - -Maintenant on a toujours pas d'option acceptable donc il va falloir creuser un peu plus. Je me suis dit qu'il nous restait une option c'est les radiateurs de processeurs de serveurs. Et oui, le radiateur noctua n'a pas beaucoup de surface côté processeur car les processeurs classiques intel et AMD sont plutôt petits, mais ce n'est pas le cas des processeurs de serveurs depuis plusieurs années. - -J'ai donc trouvé mon bonheur en cherchant des radiateurs de serveurs avec ce modèle : *Le Dynatron A51 !* - -Lien digitec : https://www.digitec.ch/fr/s1/product/dynatron-a51-refroidisseur-cpu-1u-pour-socket-sp6-passif-27-mm-ventirad-processeur-39319613 +Sa surface de contact est également plus adaptée : #figure( - image("/assets/radiateur.png", width:50%), - caption: [Dynatron A51], + image("/assets/radiateur_specs.png", width: 50%), + caption: [Dimensions du Dynatron A51.], ) -C'est un radiateur en cuivre fait pour être utilisé dans des serveurs fins (1U). il est beaucoup moins volumineux que les autres options disponibles, il a un TDP de 200W donc normalement ca devrait passer avec du refroidissement actif et la surface de contact est tout simplement énorme : +La pâte thermique préappliquée couvre une zone de 72 mm × 52 mm. La surface réelle du radiateur est encore plus grande, ce qui laisse de la marge pour positionner les LED et le PCB. -#figure( - image("/assets/radiateur_specs.png", width:50%), - caption: [Dynatron A51], -) - -On peut voir que de la pâte thermique est appliqués de base sur une surface de 72x52. mais la surface de refroidissement est plus grande que ca et cela veut aussi dire que ca nous laisse même de la place pour le PCB. - -La seule chose à prendre en compte c'est que le flux d'air attendu par ce genre de radiateurs est dans le sens de ses ailettes et non de haut en bas ce qui veut dire que selon la configuration du ventilateur on pourrait faire des sacrifices en performance. +Le principal point d'attention est le sens du flux d'air. Ce type de radiateur est prévu pour recevoir un flux d'air dans le sens de ses ailettes, comme dans un serveur. Si le ventilateur souffle de haut en bas, les performances peuvent être moins bonnes. La conception mécanique de la lampe devra donc tenir compte de cette contrainte. ==== Ventilateur -Ici le choix est asez vite fait. +Le choix du ventilateur dépend principalement de la tension de la batterie. La batterie prévue initialement a une tension nominale d'environ 48 V. Deux options étaient donc possibles : -J'avais deux options de classe de ventilateur comme la tension nominale de ma batterie est de 48V. ++ utiliser un ventilateur 48 V ; ++ utiliser un ventilateur 12 V avec une alimentation dédiée. -+ Un ventilateur 48V "plug and play" -+ Un ventilateur 12V qui demande de l'électronique supplémentaire +Un ventilateur 48 V aurait été la solution la plus simple sur le plan électrique. Il aurait probablement supporté la tension maximale de la batterie, qui peut atteindre environ 55 V. Cependant, cette solution présente deux inconvénients importants. -Techniquement un ventilateur 48V supporterait très certainement les 55V de la batterie pleine et clairement l'option "facile" serait d'en utiliser un. Cependant il y a deux énormes problèmes avec cette option. +D'abord, la plupart des ventilateurs 48 V disponibles chez Mouser ou Conrad sont destinés à des usages industriels ou serveur. Ils sont souvent très bruyants et leurs dimensions ne sont pas toujours adaptées au projet. Ensuite, ils sont relativement chers à l'unité. -+ La plupart des ventilateurs 48V sur Mouser ou Conrad sont des ventilateurs qui font un bruit PAS POSSIBLE et qui n'ont pas des dimensions très intéressantes -+ Ils sont étonnemment chers. Je pense que en grande quantité cela doit être différent mais la clairement même financièrement ce n'est pas intéressant. +J'ai donc choisi d'ajouter un buck 12 V afin d'utiliser un ventilateur de PC classique. Cette solution ajoute un peu de complexité au PCB, mais donne accès à un choix de ventilateurs beaucoup plus large. -J'ai donc décidé d'ajouter un Buck à mon projet pour pouvoir utiliser des ventilateurs classiques 12V même si cela ajoute une petite complexité au PCB. - -Et comme ventilateur j'ai choisi le Noctua NF-P12. La raison est que c'est un ventilateur peu onéreux mais très silencieux et qui est utilisé sur des radiateurs de processeurs Noctua. +Le ventilateur retenu est le Noctua NF-P12 redux 1700 PWM. Il est relativement peu cher, silencieux et prévu pour être utilisé sur des radiateurs de processeurs. #figure( - image("/assets/Noctua_fan.png", width:30%), - caption: [Noctua NF-P12], + image("/assets/Noctua_fan.png", width: 30%), + caption: [Noctua NF-P12.], ) Lien Digitec : https://www.digitec.ch/fr/s1/product/noctua-ventilateur-nf-p12-redux-1700-pwm-120-mm-1-x-ventilateur-pc-12826297 -=== Batterie +=== Batterie -WIP +Cette partie reste à compléter. Il faudrait notamment expliquer : + ++ le nombre de cellules prévu ; ++ la tension minimale, nominale et maximale de la batterie ; ++ la capacité visée ; ++ l'autonomie théorique à 100 W et à 200 W ; ++ les contraintes de courant ; ++ le choix de l'architecture de protection et de charge. == Choix des composants du circuit -=== MCU +=== Microcontrôleur -C'est le cerveau de notre circuit. J'ai choisi le RP2040 +Le microcontrôleur est le centre de contrôle du circuit. J'ai choisi le RP2040. -Mfr nbr : SC0914(13) +Mfr nbr : SC0914(13) Mouser nbr : 358-SC091413 #figure( - image("/assets/RP2040_schem.png", width:50%), - caption: [Schematic du RP2040], + image("/assets/RP2040_schem.png", width: 50%), + caption: [Schéma du RP2040.], ) -J'ai choisi ce MCU car j'ai de l'experience avec, il est extrèmement abordable et il est facile à intègrer. +J'ai choisi ce microcontrôleur car j'ai déjà de l'expérience avec lui, il est très abordable et il est relativement facile à intégrer. -Si il y avait besoin de connection sans fil, de très faible consommation ou de beaucoup de calculs de floats la reflexion aurait été différente mais pour notre application il est largement suffisant. +Si le projet avait demandé une connexion sans fil, une très faible consommation ou beaucoup de calculs en virgule flottante, le choix aurait probablement été différent. Pour cette application, le RP2040 est largement suffisant. -Raspberry Pi propose un -#link("https://pip-assets.raspberrypi.com/categories/814-rp2040/documents/RP-008279-DS-1-hardware-design-with-rp2040.pdf?disposition=inline")[ - guide -] -très complet qui donne des indications précieuse sur comment bien intègrer le RP2040 dans notre design. +Raspberry Pi propose un #link("https://pip-assets.raspberrypi.com/categories/814-rp2040/documents/RP-008279-DS-1-hardware-design-with-rp2040.pdf?disposition=inline")[guide] très complet qui donne de nombreuses recommandations pour intégrer correctement le RP2040 dans un design. -Cependant, ce MCU demand un certain nombre de composants accessoires pour bien fonctionner. +Cependant, ce microcontrôleur demande plusieurs composants externes pour fonctionner correctement. -==== Composants accessoires +==== Composants associés au RP2040 #figure( - image("/assets/RP2040_components.png", width:50%), - caption: [Schematic de la flash et du crystal], + image("/assets/RP2040_components.png", width: 50%), + caption: [Schéma de la mémoire flash et du quartz.], ) -Pour fonctionner, le RP2040 a besoin d'un certain nombre de composants supplémentaires que certains MCU concurrents emportent avec eux (Ex des ESP32) en voici la liste : +Contrairement à certains microcontrôleurs qui intègrent davantage d'éléments en interne, le RP2040 nécessite plusieurs composants externes : -+ Des capa de découplage -+ Des switchs de reset et de bootsel -+ Une flash -+ Un oscillateur -+ Une entrée USB pour flasher le firmware ++ des condensateurs de découplage ; ++ des boutons de reset et de BOOTSEL ; ++ une mémoire flash externe ; ++ un quartz ; ++ une interface USB pour programmer le firmware. -Pour les capa, en principe on devrait en avoir un par pin d'alimentation mais le guide fournis par raspberry indique que on peut s'en sortir avec un peu moins. +Pour les condensateurs de découplage, le principe idéal serait d'en placer un par broche d'alimentation. Le guide matériel de Raspberry Pi indique cependant qu'il est possible d'en utiliser un peu moins si le placement et le routage restent corrects. -Pour les switchs de RST et de BOOT on en reparle dans la partie IHM mais seul le switch de BOOT est obligatoire car sans lui on ne peut pas reprogrammer le MCU. +Les boutons de reset et de BOOTSEL sont liés à l'interface homme-machine, mais seul le bouton BOOTSEL est vraiment indispensable. Sans lui, il devient beaucoup plus difficile de reprogrammer le microcontrôleur. -Pour la flash il y a des options proposées dans la documentation de Raspberry mais j'ai préfèré en choisire une générique sur Mouser +Pour la mémoire flash, Raspberry Pi propose plusieurs références compatibles dans sa documentation. J'ai choisi une mémoire générique disponible chez Mouser : -Mfr nbr: IS25LP032D-JNLE-TR -Mouser nbr: 870-IS25LP032DJNLETR +Mfr nbr : IS25LP032D-JNLE-TR +Mouser nbr : 870-IS25LP032DJNLETR -C'est une flash de 32Mb ou 4MB ce qui suffit largement pour notre utilisation. elle est même plutôt overkill mais c'est pour autoriser plus tard l'utilisation d'un écran et donc pouvoir stocker de petites images pour une UI. +Il s'agit d'une mémoire de 32 Mbit, soit 4 MB. C'est largement suffisant pour l'application actuelle. Cette capacité est même supérieure au besoin immédiat, mais elle laisse de la marge pour une future interface graphique avec de petites images stockées en mémoire. -Pour l'oscillateur j'ai choisi le même que celui utilisé avec les raspberry pico. +Pour le quartz, j'ai choisi le même modèle que celui utilisé sur le Raspberry Pi Pico : -Mfr nbr: ABM8-272-T3 -Mouser nbr: 815-ABM8-272-T3 +Mfr nbr : ABM8-272-T3 +Mouser nbr : 815-ABM8-272-T3 -Et pour l'USB il faut simplement deux resistances de 27 ohm comme indiqué dans la documentation de Raspberry pour complèter l'impédence interne des pistes D+ et D-. +Pour l'USB, il faut notamment ajouter deux résistances série de 27 Ω sur les lignes D+ et D-. Elles complètent l'impédance interne des broches USB du RP2040, comme recommandé par la documentation de Raspberry Pi. -=== Drivers de LEDS +=== Drivers de LED + +#deux-images("/assets/led_driver_V1.png", "/assets/led_driver_V2.png", [Driver utilisé dans la V1 à gauche et driver utilisé dans la V2 à droite.]) + +Pour la V1 du PCB, j'ai utilisé un petit driver par canal. Comme chaque LED possède deux canaux, cela donne deux drivers par LED, soit huit drivers au total. + +Pour la V2, je suis passé à un driver plus puissant capable de gérer deux canaux à la fois. Quatre drivers suffisent donc pour l'ensemble des LED. + +Le driver de la V1 est le suivant : + +Mfr nbr : ZXLD1366ET5TA +Mouser nbr : 522-ZXLD1366ET5TA +Prix unitaire : 2,13 CHF +Prix total pour huit pièces : 17,04 CHF + +Le driver de la V2 est le suivant : + +Mfr nbr : ALT80800KLPATR +Mouser nbr : 250-ALT80800KLPATR +Prix unitaire : 1,43 CHF +Prix total pour quatre pièces : 5,72 CHF + +Le driver utilisé en V1 peut théoriquement supporter 1 A, ce qui suffit pour un seul canal de LED. Son boîtier est compact, mais les composants externes nécessaires prennent de la place. La dissipation thermique du boîtier est aussi limitée, car il ne possède pas de pad thermique sous le composant. + +Cette solution est plus chère, mais elle permet de contrôler individuellement chaque canal. Elle est aussi relativement simple à piloter. + +Le driver utilisé en V2 est nettement moins cher et peut gérer jusqu'à 2,5 A. Il peut donc alimenter deux canaux de LED à pleine puissance. Dans cette application, il suffit de contrôler séparément les canaux chaud et froid, ce qui rend cette solution adaptée. + +En revanche, ce driver est plus difficile à intégrer correctement que celui de la V1. + +==== Composants associés aux drivers + +Pour la V1, deux erreurs principales ont été identifiées autour des drivers de LED. + +La première concerne la résistance du filtre PWM, qui était de 10 kΩ. Cette valeur était trop élevée et empêchait les LED de s'éteindre correctement avec un rapport cyclique très faible. + +La seconde concerne l'absence d'une résistance de pull-down de 4,7 kΩ sur la broche ADJ. Au démarrage ou pendant un reset du microcontrôleur, les broches de contrôle peuvent rester flottantes. Dans ce cas, la tension VREF, proche de 1,2 V, peut activer les drivers. Cela provoquait un flash des LED au démarrage et les LED pouvaient aussi rester allumées pendant la programmation du microcontrôleur. + +Pour la V2, en plus des condensateurs de découplage, des inductances et des diodes classiques, plusieurs choix ont été faits : + ++ éviter les condensateurs électrolytiques, car leur durée de vie diminue dans les environnements chauds ; ++ utiliser plusieurs condensateurs céramiques en parallèle lorsque la capacité nécessaire est élevée ; ++ choisir des inductances capables de supporter le courant sans saturation excessive ni résistance série trop élevée ; ++ ajouter des résistances de ballast pour limiter le courant dans les LED et éviter un déséquilibre entre les modules. + +Les résistances de ballast limitent le courant à environ 800 à 850 mA par canal. Elles réduisent le risque qu'un driver fournisse un courant global correct, mais mal réparti entre plusieurs LED. + +=== Alimentations à découpage + +#deux-images("/assets/BucksV1.png", "/assets/BucksV2.png", [Alimentations utilisées dans la V1 à gauche et dans la V2 à droite.]) + +Le circuit fonctionne avec une tension batterie relativement élevée, comprise approximativement entre 40 V et 55 V dans l'architecture initiale. Il faut donc générer plusieurs tensions plus basses pour les circuits auxiliaires. + +Les drivers de LED possèdent leur propre étage de conversion. Il n'est donc pas nécessaire d'ajouter une alimentation dédiée pour les LED elles-mêmes. + +Dans la V1, seules deux tensions auxiliaires étaient nécessaires : + ++ 3,3 V pour l'électronique de contrôle ; ++ 12 V pour le ventilateur. + +Le buck 3,3 V fonctionnait correctement. En revanche, le buck 12 V posait problème. Le régulateur choisi était ancien et l'inductance utilisée était beaucoup trop petite. Cette erreur a rendu le PCB plus volumineux que nécessaire à cause des gros condensateurs, et surtout le circuit se comportait presque comme un court-circuit à la mise sous tension. + +Dans la V2, l'alimentation est plus complexe, car plusieurs fonctions supplémentaires ont été ajoutées. + +Deux sources de 3,3 V sont prévues. La première provient de l'USB, afin de pouvoir alimenter le microcontrôleur sans brancher la batterie. La seconde provient de la batterie, pour l'utilisation normale de la lampe. + +Dans la V1, chaque alimentation prenait directement la tension batterie en entrée. Dans la V2, le buck 12 V abaisse d'abord la tension batterie, puis le buck 3,3 V part du 12 V. Cela permet d'utiliser des composants moins chers et plus compacts pour générer le 3,3 V. + +Le buck 12 V a aussi été remplacé par un composant plus récent, qui demande des composants externes plus raisonnables et occupe beaucoup moins de place tout en conservant une capacité de courant suffisante. + +Enfin, l'écran ajouté dans la V2 demande une alimentation de 14 V. J'ai donc prévu un boost partant du 3,3 V pour générer cette tension. Ce choix permet, en principe, d'alimenter l'écran même lorsque seule l'alimentation USB est branchée. + +==== Commutation automatique du 3,3 V + +Une des fonctions ajoutées dans la V2 est la possibilité d'utiliser toutes les fonctions du PCB, sauf les LED de puissance, directement depuis l'USB. #figure( - grid( - columns: 2, // 2 means 2 auto-sized columns - gutter: 2mm, // space between columns - image("/assets/led_driver_V1.png", width: 100%), - image("/assets/led_driver_V2.png", width: 100%), - ), - caption: "Driver utilisé dans la V1 à gauche et celui utilisé dans la V2 à droite" + image("/assets/psu_autoswitch.png", width: 50%), + caption: [Circuit de commutation automatique des alimentations 3,3 V.], ) -Pour la V1 du PCB j'ai utilisé une approche à 1 petit driver par canal (donc 2 par LED et 8 en tout) alors que pour la V2 je suis passé sur un plus gros driver qui peut gèrer deux canaux à la fois (4 en tout) +Cette fonction évite de devoir brancher la batterie pour déboguer le firmware ou naviguer dans les menus de la lampe. -Le driver de la V1 est le : - -mfr nbr: ZXLD1366ET5TA -Mouser nbr: 522-ZXLD1366ET5TA - -Prix unitaire: 2,13 CHF tot: 17,04CHF - -Le driver de la V2 est le : - -mfr nbr: ALT80800KLPATR -mouser nbr: 250-ALT80800KLPATR - -Prix unitaire: 1,43 tot: 5,7CHF - -Le driver de la V1 peut en théorie supporter 1A ce qui est suffisant pour un seul canal de LED et son form factor a beau être petit, ses composants accessoires ne le sont pas et la dissipation thermique du package peut laisser à désirer car il n'y a pas de pad sous le composant en plus de sa petite taille. - -En plus cette option est très onéreuse comparé à la V2 mais elle permet de contrôler individuellement chaque canal de led et les chips sont assez simple à driver. - -Le driver de la V2 est bien moins onéreux et peut en plus gèrer 2.5A donc deux canaux de LEDS à pleine balle sans soucis. Comme dans notre cas, en théorie on n'a que le canal chaud et froid à driver indépendemment ca ne pose pas de problème. - -Cependant il est tout de même plus difficile à implémenter comparé à celui de la V1. - -==== Composants accessoires - -Pour la V1 je ne vais pas trop m'étendre dessus à part pour dire que la résistance de 10K était trop grande et qu'il manquait une pull down de 4.7k. - -La première erreur fait qu'il était impossible d'éteindre la LED même avec un PWM très bas et la seconde est plus subtile, le soucis est que quand le MCU démarre ou redémarre les pins de contrôles sont laissées flottantes et donc VREF qui est de base autout de 1.2V prime et allume les drivers ce qui fait que les leds flashent au démarrage ce qui est pénible et quand on flash le MCU elles restent allumées. - -Pour la V2 en plus des capacités de découplage selfs et diodes normales il y a quelques petits détails supplémentaire. - -+ Je ne voulais plus utiliser de capaciteurs electrolythiques car leur durée de vie est limitée surtout dans des environnements plutôts chauds ce qui est notre cas. Cela veut dire que j'ai choisi de partir sur des capa céramiques en série pour atteindre la capacité demandée dans certains cas. -+ La self est le composant le plus massif mais impossible de trouver plus petit avec le courant qui peuvent passer qui aient une resistance interne pas trop horrible. Le but n'est pas d'avoir un four sur mon PCB par ce que j'ai voulu trouver l'inductance la moins chère possible. -+ J'ai ajouté des resistance de ballast qui empêchent le courant qui passe dans les leds de dépasser les 800-850ma. Cela permet d'éviter que le driver envoie un courant correct mais désequilibré ce qui pourrait endommager une led. - -=== Alimentation (bucks) - -#figure( - grid( - columns: 2, // 2 means 2 auto-sized columns - gutter: 2mm, // space between columns - image("/assets/BucksV1.png", width: 100%), - image("/assets/BucksV2.png", width: 100%), - ), - caption: "Bucks utilisés dans la V1 à gauche et ceux de la V2 à droite" -) - -Pour l'alimentation de mon circuit, comme on travaille avec une tension relativement élevée (entre 40 et 55V) on doit descendre la tension pour nos composants accessoires. Les drivers de leds ont un buck interne donc pas besoin de s'en soucier. - -Dans la V1 on avait uniquement besoin de 3.3V pour l'électronique et de 12V pour le ventilateur. C'est pour ca que il y a moins de chips. - -L'erreur a été de choisir un très vieux driver le buck 12V et une self beaucoup trop petite. Cela a rendu le PCB plus gros que nécessaire à cause des immenses capacités et cela bloquait le circuit entier car la demande en courant était proche du court circuit à cause du mauvais dimensionnement des composants. Le buck 3.3V n'avait pas de problème et fonctionnait très bien. - -Dans la V2 on a un peu plus de complexité à cause des circuits supplémentaires et de features ajoutées. - -On a besoin de deux bucks 3.3v différents car dans le second PCB on peut alimenter le MCU sans forcément changer la batterie. Cela veut dire qu'on doit avoir un chip qui convertis le 5V du VBUS quand l'USB est connecté et un chip qui fait convertis la tension de la batterie en 3.3V en opération normale. - -En plus de ca, dans la V1 chaque chip prenait la tension de la batterie et l'adaptait. Désormais c'est le buck 12V qui descend la tension et le buck 3.3V part des 12V pour descendre à 3.3V. Cela permet de grandement réduire le prix du chip et des composants accessoires nécessaires pour chaque buck. - -Le bukc 12V a été remplacé par une version bien plus récente qui demande des composants externes biens plus cohérents et qui prend des ordres de magnitudes moins de place tout en gardant les mêmes capacités de courant. - -Dernière subtilité, l'écran ajouté dans la V2 du PCB a besoin d'une alimentation 14V et donc j'ai choisi de prendre un boost qui part des 3.3V et qui monte la tension à 14V. J'ai choisi de partir de 3.3V car cela permet d'alimenter l'écran même sans que la batterie soit connectée. - -==== Switch automatique d'alim 3.3v - -Une des features ajoutées dans la V2 du PCB est la possibilités d'utiliser toutes les fonctions du PCB à part les LEDS directement depuis une alimentation USB. - -#figure( - image("/assets/psu_autoswitch.png", width:50%), - caption: [chip d'autoswitch des alimentations], -) - -Cela permet de ne pas avoir besoin de brancher la batterie pour debugger ou se balader dans les menus de la lampe ce qui est très pratique. - -C'est ce chip qui s'occupe de changer automatiquement l'alimentation 3.3V avec une priorité pour le 3.3V qui vient de la batterie car il peut delivrer plus de courant et cela permet de retirer l'USB a tout moment si la batterie est branchée. +Le composant de commutation sélectionne automatiquement la source 3,3 V disponible. La priorité est donnée au 3,3 V généré depuis la batterie, car cette source peut fournir davantage de courant. Cela permet aussi de retirer le câble USB à tout moment si la batterie est branchée. === BMS #figure( - image("/assets/bms.png", width:100%), - caption: [Circuit de protection de la batterie dans sa version 2], + image("/assets/bms.png", width: 100%), + caption: [Circuit de protection de la batterie dans sa version 2.], ) -Le bms est le composant le plus pénible de tout le circuit car il demande énormément de composants passifs et il est très facile de faire des erreurs. +Le BMS est probablement la partie la plus délicate du circuit. Il demande beaucoup de composants passifs et il est facile de faire des erreurs de câblage ou d'interprétation de la datasheet. -Dans la première version du PCB, il y avait un certain nombre d'erreurs, la pire êtant que j'avais branché regsrc à VBATT ce qui a tué le chip. Dans certains schematics simplifiés il était indiqué qu'on pouvait le faire mais après relecture de la documentation, quand on dépasse les 25V de VBATT il était demandé d'utiliser un mosfet suiveur pour décendre la tension. +Dans la première version du PCB, plusieurs erreurs étaient présentes. La plus importante concernait la broche REGSRC, que j'avais reliée directement à VBATT. Certains schémas simplifiés donnaient l'impression que cette connexion était possible, mais une relecture plus attentive de la documentation a montré que ce n'était pas correct au-delà d'environ 25 V. Pour une batterie de tension plus élevée, il faut utiliser un montage avec MOSFET suiveur afin de réduire la tension appliquée à REGSRC. -Une des particularité est que comme la batterie est coupée en "low side" (On coupe le GND) avec un Mosfet, cela peut poser un certain nombre de problème si tout le circuit n'est pas éteins. +Une autre particularité du circuit vient du fait que la batterie est coupée côté low-side, c'est-à-dire sur le retour de masse. Cette architecture peut poser problème si le BMS reste actif alors que le reste du circuit est éteint. -Dans notre cas, le BMS est toujours actif quand le reste du circuit s'éteins et donc comme on coupe la référence de ground, on pourrait avoir du 55V qui arrive depuis les lignes de communication entre le BMS et le circuit éteins. +Dans ce projet, le BMS reste alimenté lorsque le reste du circuit est coupé. Comme la référence de masse du circuit principal peut être interrompue, des tensions dangereuses ou incohérentes peuvent apparaître sur les lignes de communication entre le BMS et le microcontrôleur. -Il a donc fallu isoler le bus I2C et la pin Alert entre BMS et MCU. +Pour éviter ce problème, il a fallu isoler le bus I2C ainsi que la broche ALERT entre le BMS et le microcontrôleur. -Pour la pin alert, j'ai utilisé un simple optocoupleur alors que pour le bus I2C j'ai du utiliser un chip qui s'en occupe. +La broche ALERT est isolée avec un optocoupleur simple. Pour le bus I2C, j'ai utilisé un circuit spécialisé d'isolation. -Ensuite le dernier composant intéressant je dirais c'est la shunt qui permettra ensuite au BMS de savoir combien de courant passe dans le circuit, information ensuite disponible pour le MCU avec la communication I2C. +Le dernier élément important est la résistance shunt. Elle permet au BMS de mesurer le courant qui traverse le circuit. Cette information peut ensuite être transmise au microcontrôleur par I2C. -=== Interface Homme Machine +=== Interface homme-machine #figure( - image("/assets/ihm.png", width:100%), - caption: [IHM de la V2], + image("/assets/ihm.png", width: 100%), + caption: [Interface homme-machine de la V2.], ) -Pour le contrôle de la carte il y a plusieurs options : +La carte peut être contrôlée avec plusieurs éléments : -- Un potentiomètre pour l'intensité lumineuse -- Un encodeur pour la couleur de la lumière -- Un bouton pour passer en mode blackout "éteindre les leds" (V2 uniquement) -- Des leds de debug sur la carte d'IHM et proche du MCU -- Des boutons pour RST le MCU/BMS ou passer le MCU en mode bootloader -- Un écran pour afficher les informations des menus (V2 uniquement) ++ un potentiomètre pour régler l'intensité lumineuse ; ++ un encodeur rotatif pour régler la température de couleur ; ++ un bouton blackout pour éteindre rapidement les LED ; ++ des LED de debug sur la carte d'IHM et près du microcontrôleur ; ++ des boutons pour réinitialiser le microcontrôleur ou le BMS ; ++ un bouton BOOTSEL pour mettre le microcontrôleur en mode bootloader ; ++ un écran pour afficher les menus et les informations de fonctionnement. -Sur le PCB V2, la partie qui emporte encodeur, potentiometre, bouton et écran est une carte déportée connectée avec un connecteur style écran. +Sur le PCB V2, les éléments de commande principaux sont placés sur une carte déportée. Elle contient l'encodeur, le potentiomètre, le bouton et l'écran. Elle est reliée à la carte principale par un connecteur de type écran. #figure( - image("/assets/screen.png", width:100%), - caption: [Schematic de l'écran], + image("/assets/screen.png", width: 100%), + caption: [Schéma de l'écran.], ) -=== Pinout +=== Connecteurs et pinout #figure( - image("/assets/connecteurs.png", width:100%), - caption: [Schematic de l'écran], + image("/assets/connecteurs.png", width: 100%), + caption: [Connecteurs et points d'accès du circuit.], ) -Pour la communication entre les trois cartes ou l'exterieur ou le debug on a plusieurs pins ou pads disponibles. +Plusieurs connecteurs et pads permettent d'interagir avec les différentes cartes, avec l'extérieur et avec les points de debug. -Les plus évidents sont les pads de batterie ainsi que les pads pour connecter les leds. +Les connexions les plus importantes sont les pads de batterie et les pads de connexion des LED. -Ensuite on a les différents JST qui sont la pour connecter la carte BMS au PCB principal ou pour connecter les cellules de la batterie au BMS. +Des connecteurs JST sont utilisés pour relier la carte BMS au PCB principal, ainsi que pour connecter les cellules de la batterie au BMS. -Pour la communication entre le PCB principal et la carte IHM, on a des connecteurs style connecteur d'écran de 20pins. +La communication entre le PCB principal et la carte d'IHM passe par des connecteurs de type écran à 20 broches. -Pour le ventilateur on a aussi un connecteur MOLEX qui est standart pour des ventilateurs 12V de PC classiques. +Le ventilateur utilise un connecteur Molex standard pour ventilateur PC 12 V. -Pour le debug on a un "power panner" qui regroupe toutes les tensions disponibles sur la carte. Quand l'USB seul est connecté, le 5V,3.3V et le 14V sont en principe disponibles et avec la batterie branchée le 12V et le VBAT sont également disponibles. +Pour le debug, un power panel regroupe les différentes tensions disponibles sur la carte. Lorsque seul l'USB est connecté, le 5 V, le 3,3 V et le 14 V devraient être disponibles. Lorsque la batterie est branchée, le 12 V et VBAT sont également accessibles. -Cela permet de vérifier que tous les rails fonctionnent et cela peut aussi permettre d'étendre les capacités de la carte dans le futur. +Ce panneau permet de vérifier rapidement que les rails d'alimentation fonctionnent. Il peut aussi servir à étendre les possibilités de la carte dans une future version. -Pour le debug on a aussi des pins qui permettent de contrôler les drivers de leds sans le microcontrolleur. Cela peut permettre de faire des tests dans le cas ou le MCU serait indisponible (Ce qui a été très utile pendant la phase de tests). +Des broches de debug permettent également de contrôler les drivers de LED sans passer par le microcontrôleur. Cette possibilité s'est révélée très utile pendant les tests, notamment lorsque le microcontrôleur n'était pas encore fonctionnel. === Mapping des GPIO -#figure( - grid( - columns: 2, // 2 means 2 auto-sized columns - gutter: 2mm, // space between columns - image("/assets/GPIO_V1.png", width: 100%), - image("/assets/GPIO_V2.png", width: 100%), - ), - caption: "Utilisation des GPIO sur les deux versions du PCB" -) +#deux-images("/assets/GPIO_V1.png", "/assets/GPIO_V2.png", [Utilisation des GPIO sur les deux versions du PCB.]) -Ci-dessus, l'utilisation des pins du RP2040. C'est toujours utile de garder ce genre d'information pour la programmation du microcontrolleur. +La figure ci-dessus présente l'utilisation des broches du RP2040 sur les deux versions du PCB. Ce type de schéma est utile pour le développement firmware et pour le débogage. -Une des améliorations que je ferais si je faisais une V3, c'est de ne pas assigner les GPIO dabord mais de commencer par poser les composants sur le PCB et ensuite de placer les GPIO de sorte à rendre le routage plus simple. En effet, avec le RP2040, on peut rerouter presque nimporte quoi sur nimporte quelle pin. +Une amélioration importante pour une éventuelle V3 serait de ne pas assigner les GPIO trop tôt. Il serait plus efficace de placer d'abord les composants sur le PCB, puis de choisir les GPIO en fonction du routage le plus simple. Le RP2040 permet de rediriger de nombreuses fonctions numériques sur presque n'importe quelle broche, ce qui donne beaucoup de liberté. -Sur la V2 du PCB il a été choisi de ne plus laisser toutes les pins à disposition sur le bord du PCB car à l'exception de 2 GPIO, tout était déja utilisé pour la carte elle même. +Sur la V2, presque toutes les GPIO sont utilisées par la carte elle-même. Il a donc été décidé de ne plus exposer toutes les broches sur le bord du PCB, contrairement à la première version. -=== Fabrication et problèmes +== Fabrication et problèmes rencontrés -==== Montage PCB 1 +=== Montage du PCB V1 + +#deux-images("/assets/PCB_1.jpeg", "/assets/PCB_1_FINAL_FORM.jpeg", [Réception et montage du premier PCB.]) + +Le montage du premier PCB s'est globalement bien passé, malgré une contrainte importante : je n'avais commandé qu'une seule BOM. Si un composant était perdu ou endommagé, il n'y avait donc pas de pièce de rechange immédiate. + +Le PCB est assez grand et utilise une finition ENIG. Cette finition était nécessaire chez Eurocircuits, car le pas du RP2040 est de 0,4 mm et les composants avec un pas inférieur à 0,5 mm imposent une finition or. + +La stratégie consistant à regrouper deux PCB sur un même panneau a bien fonctionné. La seule limite est qu'il vaut mieux souder les composants traversants après avoir séparé les cartes. Sinon, les morceaux de PCB qui maintiennent le panneau peuvent devenir difficiles à retirer. + +Une fois le PCB monté, plusieurs problèmes sont apparus. + +=== Problèmes majeurs de la V1 + +Le premier problème est apparu dès la mise sous tension : le circuit consommait autant de courant que l'alimentation pouvait fournir, comme s'il y avait un court-circuit. Pourtant, aucune liaison directe entre GND et VBATT n'était visible. + +Le problème venait finalement du rail 12 V. L'inductance choisie était beaucoup trop petite, aussi bien physiquement qu'électriquement. Elle était d'ailleurs visuellement disproportionnée par rapport aux autres composants du rail 12 V. + +Une inductance beaucoup trop faible peut faire se comporter un buck comme une charge presque en court-circuit. À chaque cycle de commutation, le courant augmente trop vite. Si le courant de saturation de l'inductance est dépassé, son inductance effective diminue encore, ce qui aggrave le problème. Dans ce cas, elle se comporte presque comme un simple fil, ce qui entraîne une demande de courant excessive. + +Le problème a pu être contourné en dessoudant la patte enable du buck 12 V et en la reliant à l'entrée batterie de manière à désactiver ce régulateur. + +Cela signifie que, sur la V1, le rail 12 V est inutilisable. Il n'est donc pas possible de brancher directement le ventilateur sur la carte. + +Avec le buck 12 V désactivé, la carte a pu être connectée à un ordinateur via l'USB-C. Le RP2040 apparaissait bien comme périphérique de stockage, ce qui indiquait que l'interface USB et le mode bootloader fonctionnaient. + +Cependant, après le flash d'un firmware, le RP2040 réapparaissait immédiatement en mode bootloader au lieu d'exécuter le code. Le problème venait du footprint de la mémoire flash : deux broches avaient été interverties. Le microcontrôleur ne pouvait donc pas écrire correctement le programme dans la flash ni démarrer depuis celle-ci. + +La réparation a été faite avec des fils très fins afin de recâbler correctement les broches concernées. #figure( - grid( - columns: 2, // 2 means 2 auto-sized columns - gutter: 2mm, // space between columns - image("/assets/PCB_1.jpeg", width: 100%), - image("/assets/PCB_1_FINAL_FORM.jpeg", width: 100%), - ), - caption: "Reception et montage du premier PCB" + image("/assets/GodDidNotExcpectThat.jpeg", width: 60%), + caption: [Réparation manuelle du footprint de la mémoire flash.], ) -Le montage s'est plutôt bien passé malgrés le fait qu'il n'y aie qu'une seule BOM. Cela veut dire que si je perdais un composant j'étais fichu. +Cette réparation a permis de rendre la carte fonctionnelle. J'ai également découvert que, comme la mémoire flash choisie n'était pas exactement celle utilisée par défaut par Raspberry Pi, il fallait adapter la chaîne de compilation pour générer un firmware compatible. -On peut voir que le PCB est assez grand et il a la finition ENIG car le pas de mon MCU est trop fin (0.4mm et eurocircuit oblige la finition OR en dessous de 0.5mm) +Après cette correction, il a été possible de programmer le RP2040 et d'exécuter du code. -Ce qui est bien c'est que la stratégie de deux PCB en un a fonctionné sans accroc (avec la seule limite qu'il vaut mieux souder les composants through hole APRES avoir separé les PCB sinon on peut se retrouver à ne pas avoir la place pour retirer les morceaux de PCB qui tiennent l'ensemble). +Un dernier doute concerne la capacité thermique des petits drivers de LED de la V1. Leur boîtier est compact et ne possède pas de pad thermique, ce qui limite fortement leur dissipation. -Mais maintenant que on a un PCB monté on peut directement passer aux problèmes :) +=== Petits problèmes de la V1 -==== Problèmes majeurs +Les autres problèmes identifiés sur la V1 sont les suivants : -Le premier problème est que en voulant alimenter le PCB on peut voir qu'il y a un short quelque part. Le GND et le VBATT ne semblent pas être bridgé nul part mais la consommation du circuit est toujours à la limite de ce qu'on lui donne. ++ résistance du filtre PWM trop élevée, remplacée de 10 kΩ par 1 kΩ afin de permettre l'extinction complète des LED ; ++ absence d'une résistance de pull-down de 4,7 kΩ sur la broche ADJ des drivers de LED, ce qui provoquait un flash au démarrage ; ++ potentiomètre câblé dans le mauvais sens ; ++ BMS mal dimensionné, ce qui a endommagé le composant ; ++ trous de fixation du radiateur légèrement mal positionnés. -Il a été découvert que le problème était sur le rail 12V. L'inductance choisie était bien trop petite (d'ailleurs elle fait vraiment ridicule comparée aux autres composant du rail 12V qui sont énormes) +Le problème le plus grave du BMS était lié à la broche REGSRC. Certains schémas simplifiés la montraient reliée directement à VBAT, mais ce n'est pas possible dans cette architecture à tension élevée. -De ce que j'ai compris, une inductance beaucoup trop petite peut donner l'impression d'un short au niveau de l'alimentation car cela fait que à chaque cycle du buck le courant augmente de manière assez dramatique et le courant de saturation de la self est largement dépassé ce qui la rend encore plus faible en UH et donc elle se comporte presque comme un cable normal ce qui empire encore la situation. +=== Bilan de la V1 -Ce problème a pu être contourné en désoudant la patte enable du buck 12V et la relier avec un câble à l'entrée de la batterie ce qui le désactive. +La première version du PCB comporte plusieurs erreurs, mais la majorité ont pu être contournées par des réparations de fortune. La carte a finalement pu fonctionner en grande partie. -Cela veut dire que dans la version 1 du PCB le rail 12V est inopérant et qu'on ne peut donc pas brancher directement de ventilateur dessus. +Les deux fonctions réellement manquantes sur cette version sont le rail 12 V pour le ventilateur et le BMS. -Avec le buck 12V desactivé, le circuit a pu être connecté à mon laptop en utilisant le port USB-C. +La V1 n'est donc pas un échec complet. Elle a même servi à réaliser la plupart des tests, car la V2 est arrivée tard dans le développement et a demandé beaucoup de temps de débogage. La V2 n'a pas été conçue parce que la V1 était inutilisable, mais parce qu'elle permettait de corriger les défauts identifiés et d'ajouter de nouvelles fonctions. -Je pouvais voir le RP2040 apparaitre dans mon explorateur de fichier ce qui est super, mais quand j'uploadais du code dessus il réaparaissait dans mon explorateur juste après alors qu'il est sensé lancer le code que je lui ai donné. +=== Montage du PCB V2 -J'ai localisé le problème, c'est que le footprint de la flash a été raté... Deux pins ont été interchangées et donc le MCU ne pouvait pas écrire de code ou booter dessus. +#deux-images("/assets/PCB_2.jpeg", "/assets/PCB_2_ASSEMBLED.jpeg", [Réception et montage du second PCB.]) -Cela a été règlé de la manière la plus stressante pour les yeux de tous les temps : +La V2 est nettement plus compacte que la première itération. Elle est aussi beaucoup plus dense. + +L'objectif de cette version était de corriger les problèmes de la V1, d'ajouter de nouvelles fonctions et d'améliorer la robustesse thermique du design. + +Le montage s'est globalement bien passé, même si plusieurs ponts de soudure ont dû être réparés. Le placement du RP2040 et du connecteur USB-C n'était pas suffisamment précis, ce qui a causé plusieurs difficultés pendant le débogage. + +Dès la première mise sous tension par USB, la carte ne fonctionnait pas. + +=== Débogage de la V2 + +Le premier problème a été identifié rapidement grâce au power panel ajouté sur la V2. Le rail 5 V était correct, mais le rail 3,3 V était lui aussi à 5 V. + +L'erreur venait du choix du composant : j'avais sélectionné un régulateur 5 V au lieu d'un régulateur 3,3 V. Cette erreur a appliqué 5 V sur le rail 3,3 V, ce qui est dangereux pour les composants alimentés par ce rail. + +Les deux composants les plus sensibles étaient le RP2040 et sa mémoire flash. Comme je n'avais pas de pièces de rechange immédiatement disponibles, il a fallu attendre une nouvelle commande. + +Pendant ce temps, j'ai aussi constaté que le boost 14 V ne fonctionnait pas. Ce problème n'est pas encore résolu. Après vérification du schéma et des soudures, aucune erreur évidente n'a été trouvée. Le remplacement du composant serait possible, mais difficile, car les composants plastiques voisins risquent d'être endommagés à l'air chaud. + +Pour corriger le rail 3,3 V, j'ai commandé une version 3,3 V du composant et retiré la version 5 V. En théorie, la carte pouvait encore fonctionner depuis l'entrée batterie, car un autre régulateur 3,3 V est disponible à partir de cette source. + +Afin de gagner du temps, j'ai récupéré un RP2040 sur une carte de développement inutilisée pour remplacer celui qui avait été endommagé. #figure( - image("/assets/GodDidNotExcpectThat.jpeg", width:60%), - caption: [La simple existance de cette chose prouve que dieu n'existe pas ou qu'il nous abandonné], + image("/assets/PCB_2_REPAIR.jpeg", width: 40%), + caption: [Remplacement du microcontrôleur à l'air chaud.], ) -Mais cela fonctionne ! Je me suis aussi rendu compte que comme j'avais choisi une flash différente que celle proposée par la fondation Raspberry, je devais changer ma chaine de compilation pour que les programmes soient compatibles avec une flash générique. +Cette étape m'a permis d'apprendre la réparation à l'air chaud, mais elle a été difficile. Les composants se déplacent facilement, la chaleur affecte les composants voisins et il est facile d'aggraver la situation en essayant de corriger un défaut. -Après avoir règlé ce détail il était alors possible d'uploader du code sur le microcontrolleur et qu'il l'execute ! (Youpi) +Lors du premier remplacement, j'avais laissé trop d'étain sur le pad thermique. En chauffant, le microcontrôleur a glissé et a déplacé plusieurs condensateurs adjacents. Il a fallu tout dessouder, nettoyer et remplacer les composants concernés. -J'ai aussi des doutes sur la capacité thermique des minuscules drivers de leds qui n'ont pas de moyen d'être refroidis car ils ne disposent pas de pad thermique. +Les résistances USB de 27 Ω avaient également été perdues pendant la réparation. Je les ai remplacées temporairement par des résistances 0603 disponibles en stock, alors que le design original utilisait des 0402. -==== Petits problèmes +Après remplacement du microcontrôleur, la carte ne communiquait toujours pas avec l'ordinateur. La consommation semblait cohérente, mais aucun périphérique USB n'apparaissait. J'ai supposé que la mémoire flash pouvait aussi avoir été endommagée et j'ai attendu les pièces de remplacement. -Ici je vais parler des problèmes qui ne sont pas critiques en faisant une liste exhaustive. +Une fois le nouveau composant 3,3 V et la nouvelle flash installés, le rail 3,3 V était à nouveau à 5 V. L'erreur était plus profonde que prévu : le composant choisi n'était pas seulement une version de sortie incorrecte, c'était un boost et non un buck. -+ Mauvais choix de resistances pour le filtre PWM des drivers de leds (10k remplacés par des 1k pour que les leds puissent s'eteindre quand le MCU n'envoie pas de PWM) -+ Manque d'une pulldown de 4.7kR sur la pin ADJ des drivers de led ce qui fait un effet de flash au démarrage en attendant que le MCU démarre. -+ Le potentiometre est dans le mauvais sens... -+ Le BMS est mal designé et a brûlé -+ Les trous pour les vis du radiateur ne sont pas exactement aux bons endroits +Un boost 3,3 V est prévu pour générer 3,3 V à partir d'une tension plus faible, par exemple 1,8 V. Avec 5 V en entrée, il ne régule pas vers le bas. Dans ce cas, il laisse simplement passer l'entrée vers la sortie, ce qui explique pourquoi le 5 V USB se retrouvait sur le rail 3,3 V. -Le problème du BMS est la pin regSRC qui sur certains diagrammes du BMS est branchée directement sur VBAT alors que ce n'est en réalité pas possible. +Cette erreur de sélection de composant a endommagé un second RP2040 et une seconde mémoire flash. Il est peu probable qu'un remplacement direct par un buck compatible soit possible sans modifier le PCB. -==== Conclusion +J'ai donc retiré le boost 3,3 V, remplacé à nouveau la mémoire flash et le microcontrôleur, puis alimenté la carte autrement. -Sur cette version du PCB, il y a pas mal de pétouilles, mais j'ai réussi à en règler la majorité avec des réparations de fortune et il a fini par être fonctionnel en grande partie. +Un autre RP2040 a ensuite été endommagé à cause d'un court-circuit probablement situé sous le boîtier. Le composant n'était pas parfaitement aligné et certaines broches ont pu entrer en contact sous le chip, là où l'inspection visuelle était difficile. -Les seules features qui lui manquent vraiment sont le 12V pour le ventilateur et un BMS. +Après un troisième remplacement du microcontrôleur, la carte pouvait enfin être alimentée sans endommager de composants, mais la communication USB ne fonctionnait toujours pas. -C'est d'ailleurs sur ce PCB que se sont faits presques tous les tests vu que la V2 est arrivèe très tard dans le dévelopement du produit et que ses problèmes ont mis beaucoup de temps à être règlés donc en soit la V2 ne vient pas car la V1 est un échec. +Les lignes D+ et D- étaient en court-circuit. Après plusieurs vérifications, le problème venait finalement d'un court-circuit sous le connecteur USB-C. En retirant le connecteur à l'air chaud, le court-circuit a disparu. -==== Montage PCB V2 +Le connecteur ne pouvait cependant pas être réutilisé, car la chaleur avait déformé les pièces plastiques qui maintiennent les contacts. Un autre connecteur a donc été récupéré sur une carte défectueuse, puis soudé à la main pour éviter de l'endommager à nouveau à l'air chaud. -#figure( - grid( - columns: 2, // 2 means 2 auto-sized columns - gutter: 2mm, // space between columns - image("/assets/PCB_2.jpeg", width: 100%), - image("/assets/PCB_2_ASSEMBLED.jpeg", width: 100%), - ), - caption: "Reception et montage du second PCB" -) +Après cette réparation, les lignes USB n'étaient plus en court-circuit, mais la carte ne communiquait toujours pas avec l'ordinateur. Le problème venait finalement des résistances série USB 0603, qui avaient été ressoudées trop proches l'une de l'autre. Elles provoquaient un court-circuit difficile à voir. -Ce n'est peut-être pas forcément très évident en image comme ca, mais la V2 est bien plus compacte que la première itération et elle est également bien plus dense. +Après remplacement par des résistances 0402, le RP2040 a enfin pu être programmé. -Le but de ce design était déja de règler les problèmes de la première révision mais aussi d'y ajouter des choses et surtout de tenter de faire un design plus résilient au niveau thermique. +Un dernier problème est apparu : après un flash, il était parfois impossible de remettre la carte en mode bootloader. Le bouton BOOTSEL était défectueux, probablement à cause des nombreuses opérations de réparation à proximité. Il a été remplacé par un bouton récupéré sur l'ancienne carte BMS. -Le montage s'est bien passé avec cependant pas mal de ponts à réparer. Cette fois, je n'ai pas du être assez précis sur le placement de mon MCU et de mon USB ce qui a posé pas mal de problèmes. +Après ces réparations, la V2 est devenue programmable et utilisable. Cette phase a demandé beaucoup de temps et de persévérance, mais elle a permis d'identifier plusieurs erreurs de conception et de montage. -Et directment en branchant le circuit avec le port USB... patatra rien ne marche +=== Problèmes restants de la V2 -==== Les peripéties (Pas obligé de lire) +==== Mauvais composant sur le rail 3,3 V USB -Le debugging du premier soucis a été assez rapide, j'ai mis sur la V2 un "power pannel" (un endroit qui regroupe toutes les sources d'alimentations différentes de la carte) ce qui m'a permis de voir que le 5V était bien la et que sur le 3.3V il y avait.... Ah bah 5V aussi... +L'erreur la plus importante de la V2 est le choix d'un boost au lieu d'un buck pour générer le 3,3 V à partir de l'USB. -En gros j'avais pris un boost 5V et non 3.3V ce qui veut dire que sur le rail 3.3 il y avait du 5V ce qui n'est pas bon DU TOUT !! +Cette erreur a causé la majorité des problèmes de débogage. Sans elle, la carte aurait probablement été fonctionnelle beaucoup plus rapidement, à l'exception possible du problème de connecteur USB-C. -Ma "chance" fait que seuls deux composants n'étaient pas tolérants à cette tension plus haute étaient mon microcontrolleur et sa flash. Cependant comme je n'avais pas de spare, j'ai du attendre une commande. +Il n'est pas certain qu'une simple substitution de composant permette de corriger le problème. Il faudrait vérifier si un buck 3,3 V compatible avec le pinout et les composants passifs existants existe. -En attendant j'ai pu voir que le 14V ne fonctionnait pas et d'ailleurs c'est un problème qui n'a à ce jour pas été résolu. En effet même après révision avec Mr.Berthet mon design semble être correct et mes soudures aussi donc mystère. J'avais prévu de remplacer le chip mais malheureusement il est impossible de retirer l'ancien sans abimer les composants plastiques autout donc je ne sais pas encore comment je vais faire. +==== Boost 14 V -Pour règler ce problème de mauvais boost j'ai commandé la version 3.3V et j'ai retiré la version 5V du circuit. En théorie, cela peut encore fonctionner avec l'entrée batterie car un buck 3.3 est dispo sur l'entrée 55V. +Le circuit 14 V est bien censé être un boost. Contrairement au rail 3,3 V USB, le principe est donc correct. -Pour ne pas perdre trop de temps j'ai canibalisé un microcontrolleur d'une devboard inutilisée pour le remplacer avec celui qui avait grillé +Cependant, il ne fonctionne pas à ce jour. La cause exacte n'a pas encore été identifiée. Il pourrait s'agir du composant lui-même, d'un problème de soudure, d'une erreur dans les composants passifs ou d'une condition de charge non respectée. -#figure( - image("/assets/PCB_2_REPAIR.jpeg", width:40%), - caption: [remplacement à l'air chaud du microcontrolleur], -) +Comme le 14 V alimente l'écran, celui-ci ne peut pas encore fonctionner. Il serait possible d'injecter une alimentation 14 V externe, mais je ne l'ai pas fait pour éviter d'endommager le boost ou le reste du circuit. -Au passage j'ai pu apprendre la soudure et la réparation à l'air chaud. C'est absolument insupportable surtout au début car les composants aiment bien se balader ou pousser tous ceux en proximité et en général en essayant de réparer l'histoire on se brûle les doigts même en utilisant des pinces et on rend le tout pire. +==== Potentiomètre connecté à une broche non analogique -J'ai resoudé non sans mal le microcontrolleur mais j'avais laissé trop d'étain sur le pad thermique et donc quand j'ai chauffé le cpu a glissé et emporté avec lui toutes les capacités adjacentes ce qui a fait un carnage et il a fallu tout désouder et remplacer. +Le RP2040 permet de rediriger de nombreuses fonctions numériques vers différentes GPIO, mais ce n'est pas le cas des entrées analogiques. Le potentiomètre a été connecté à une broche qui n'est pas compatible avec l'ADC. -J'ai pu tout remettre tant bien que mal les resistances sauf les 27ohm qui s'étaient faites la malle que j'ai remplacé par des 0603 en stock (d'origine ce sont des 0402) en faisant attention à ce qu'elles ne se touchent pas (foreshadowing) +Cette erreur empêche d'utiliser directement le potentiomètre tel que prévu. Elle devra être corrigée dans une future révision. -Ensuite je suis allé tester sur le bench et je n'ai pas réussi à faire fonctionner l'histoire en passant par le buck 3.3V. La consommation paraissait cohérente mais pas de signal sur le laptop quand je le connectais. J'ai lu que c'était potentiellement à cause de la flash encore morte et donc j'ai décidé d'attendre que le remplacement arrive. +==== Défaillance de certains drivers de LED -Le boost 3.3V et la flash sont ensuite arrivés et je me suis empressés de les installer sur ma carte. Je branche la carte et la... misère toujours pas de signal et la consommation est plus basse qu'elle n'est sensée l'être. +Un problème plus tardif concerne les drivers de LED. Lors d'un test, l'application brutale de la puissance maximale a provoqué la destruction d'un driver. -Par acquis de consience je retourne sur le power pannel, et la, l'HORREUR, il y a à nouveau du 5V sur le rail 3.3v... +La cause exacte n'est pas encore connue. Plusieurs hypothèses restent possibles : -La je ne vais pas vous mentir l'ambiance est au plus bas. Comment est-ce que c'est possible que j'aie encore tout cramé sur ma carte ? Et bien je vous laisse essayer de devinner vous le lecteur, vous avez toutes les informations nécessaires. ++ problème de layout ; ++ capacité d'entrée ou de sortie mal dimensionnée ; ++ transitoire trop violent pendant le test ; ++ échauffement local ; ++ composant insuffisamment robuste pour les conditions réelles. -Ca y est? Vous avez compris ? Peut-être même que vous aviez vu depuis le début. En effet, le premier chip était bien un boost 5V, et donc quand j'ai vu une version 3.3V avec le même pinout et les mêmes composants accessoires je me suis dit "Banco" mais je faisais la une erreur. Le chip 5V n'avait pas comme seul problème sa tension de sortie. C'EST UN BOOST PAS UN BUCK !!!! Si vous aviez tické en lisant félicitation sinon vous êtes comme moi à vous frapper le front de désespoir. +Ce point devra être investigué plus précisément avant une V3. -La pièce est donc un boost qui veut sortir du 3.3V mais pas avec du 5V en entrée mais du 1.8V et il se trouve que ce modèle quand il recoit une tension plus élevée que sa sortie fixe, il laisse passer l'entrée direct et donc le 5V de l'USB a pu à nouveau se frayer un chemin sur le rail 3.3V. +==== Fonctions non testées -Je pense que sur mouser j'ai vu voltage regulator et je devais être distrait et j'ai choisi le mauvais type. C'est une terrible erreur mais fondamentalement très bête (qui ne m'arrivera plus jamais) et c'est très frustrant car non seulement je ne pourrai sûrement pas trouver de buck de remplacement 3.3V avec le même pinout et les mêmes composants accessoires, mais en plus j'ai cramé un deuxième MCU et une seconde flash. +Certaines fonctions de la V2 n'ont pas encore pu être testées par manque de temps. Il est donc probable que d'autres points d'amélioration apparaissent après une campagne de tests plus complète. -J'ai donc remplacé la flash et le MCU une deuxième fois et retiré le boost 3.3V et j'ai ensuite tout branché. +Malgré cela, la seconde itération est globalement plus réussie que la première. Elle est plus compacte, plus utilisable et améliore clairement plusieurs points importants du design. -Il se trouve que cette fois mon MCU n'avait pas été parfaitement re soudé et donc il y a eu un petit short qui l'a tué... Je ne pouvais pas voir de pont à l'exterieur mais comme une partie des contacts est sous le chip et qu'il nétait pas parfaitement droit le contact devait se faire dessous. +== Tests de puissance -Donc après avoir remplacé le MCU avec un TROISIEME j'ai pu tout assembler et brancher sans que rien ne crame. +L'alimentation de laboratoire classique ne permet pas de tester la carte à pleine puissance. J'ai donc utilisé une autre alimentation capable de fournir davantage de courant. Les tests à pleine puissance ont toutefois été limités à de courtes durées afin d'éviter d'endommager la carte avant la présentation. -Cependant impossible de communiquer avec le laptop. J'avoue que le desespoir a commencé à pointer le bout de son nez car les réparations actuelles avaient déja pris un certain temps et avaient été plutôt difficiles. +La puissance lumineuse et la chaleur générées par le système sont très importantes. Une mauvaise manipulation peut facilement être dangereuse pour les yeux ou provoquer des brûlures. -J'ai testé les pistes D+ et D- et elles etaient shortées. J'ai tout verifié, les pins de l'USB le chemin des pistes et je suis même allé jusqu'à désouder les resistances de 27ohm pour être sûr que le problème n'était pas la mais toujours un short. +Les mesures ont été réalisées avec un thermomètre afin d'estimer la température de surface des LED et des drivers. -Mr.Fourquier m'a dit que ca devait être un short SOUS l'USB et effectivement en retirant le port à l'air chaud plus de short... +L'installation de test actuelle n'est pas optimale. Les LED ne sont pas collées définitivement au radiateur. Elles tiennent principalement grâce à l'adhérence de la pâte thermique de PC utilisée pour les essais. Cette pâte a une résistance thermique plus élevée qu'une époxy thermique adaptée. Dans la version finale, les modules LED devraient être fixés avec une époxy thermique. -Sauf que avec la chaleur le plastique qui tient les pins a fondu et donc elles ne pouvaient plus faire contact donc impossible de le remettre. +Le ventilateur est branché au PCB, mais les tests se font sur une table. Le flux d'air n'est donc pas représentatif d'une intégration mécanique correcte, où l'air devrait être guidé dans le sens des ailettes du radiateur. -Il a fallu en commander un autre mais en attendant j'ai pu aller canibaliser un autre port sur une carte defectueuse de l'année passée et la remplacer sur ma carte sauf que désouder à l'air chaud et resouder à l'air chaud détruit le plastique du connecteur et donc il a fallu le retirer à nouveau. +Même à quelques dizaines de watts, la lumière produite est très intense. À forte puissance, il devient difficile d'effectuer les mesures sans être ébloui ni exposer les mains à une chaleur importante. -J'ai ensuite testé avec une autre carte en faisant super attention et en soudant à la main au fer sur ma carte le remplacement et la enfin plus de short entre D+ et D-. +Autour de 80 W, les LED peuvent rester allumées pendant plusieurs minutes sans problème apparent. Leur température monte autour de 70 °C, puis se stabilise ou augmente très lentement. Les drivers de LED restent autour de 35 °C. Une partie de cette température mesurée peut venir du rayonnement des LED elles-mêmes. -Mais toujours aucun signal sur mon laptop... la ca devenait vraiment pénible. +Au-delà de 120 à 150 W, la température des LED monte rapidement vers 70 °C. Ensuite, l'augmentation ralentit, mais la température continue de progresser progressivement vers 80 °C. J'arrête les tests à ce niveau pour éviter d'endommager les LED. -Je vous passe les détails mais en fait en resoudant les resistances 0603 après les avoir retirées pour trouver le short des lignes, je les avais resoudées trop proches, cela shortait donc les lignes mais je ne pouvais pas le voir avec le multimètre plus loin pour une raison inconnue. +Ces résultats montrent que le radiateur reçoit bien la chaleur, mais que le transfert thermique depuis les LED vers le radiateur n'est pas encore assez efficace. Une fixation avec une époxy thermique adaptée devrait améliorer ce point. -J'avais passé commande de 0402 au moment du remplacement du premier MCU heureusement et donc après remplacement je pouvais enfin flasher le firmware sur mon microcontrolleur. +Des tests plus longs et plus proches de 200 W devront être réalisés une fois le montage mécanique et la fixation thermique améliorés. -Mais après un flash, impossible de le revoir apparaitre sur le laptop pour en mettre un autre... +== Améliorations possibles pour une V3 -Il se trouve que le bouton bootsel était lui aussi defectueux (peut-être à cause de la chaleur des différents changements de flash et de microcontrolleurs) et j'ai pris le bouton du BMS première géneration pour swapper avec le defectueux et cela fonctionnait. +Plusieurs améliorations sont nécessaires pour une future version. -Et voila ! Ouf ! On arrive enfin à avoir une carte sur laquelle on peut flasher un firmware. Cette partie du projet a demandé beaucoup de résilience et ces problèmes ont pris plusieurs semaines à êtres tous réglés mais au final ca marche. +Il faudrait ajouter des thermistances SMD près des drivers afin de mesurer leur température. Le microcontrôleur pourrait alors réduire automatiquement la puissance si les drivers deviennent trop chauds. -==== Problèmes +Il faudrait aussi prévoir des thermistances directement sur les modules LED ou à proximité immédiate. Dans l'état actuel, il n'y a pas de sécurité thermique active pour protéger les LED. -Maintenant que on a passé en revue les peripéties du montage de la carte et les dégâts du boost 5V on peut passer en revue les "problèmes" que la V2 du projet comporte. +La conception mécanique doit être approfondie. Il faut prévoir un boîtier imprimé en 3D ou usiné autour de la carte, du radiateur, du ventilateur et des LED. Si la V3 reste aussi compacte que la V2, l'intégration devrait être possible, car la carte est plus petite que le radiateur. -1. Le boost 5V qui devait être un buck 3.3V +Une option serait d'utiliser un radiateur plus performant de la même famille, comme le Dynatron A53. -C'est l'erreur la plus importante je dirais et je ne pense pas qu'elle puisse être règlée juste en swapant un composant, mais peut être que si honnêtement je ne me suis pas penché assez dessus pour être sur. +#deux-images("/assets/A53.png", "/assets/A53_2.png", [Dynatron A53.]) -Sans ce problème aucunes des peripéties n'aurait eu lieu à part peut-être celle de l'USB C à replacer. +Ce modèle utilise des heat pipes situés directement sous la zone des LED. Cela pourrait améliorer la conduction de chaleur et réduire les points chauds. En principe, il pourrait même être testé avec la V2 actuelle. -2. Le boost 14V +Il serait aussi intéressant d'étudier la possibilité de passer le PCB en deux couches. Cela pourrait réduire fortement le coût. Il faudrait cependant vérifier si la disparition d'une couche dédiée à l'alimentation ne pénalise pas trop le routage, la résistance des pistes et la gestion thermique. -La c'est effectivement sensé être un boost, pas de piège cette fois, mais malheureusement impossible de trouver quel est son problème à ce jour. Je ne sais donc pas comment le règler à moins d'abimer mon PCB en remplacant le chip original. (Quand je me lancerait dans la Fabrication de la V3 je le ferai) +Pour la V3, le mapping des GPIO devrait être choisi après le placement des composants. Comme le RP2040 permet de router presque toutes les fonctions numériques vers différentes broches, il est plus logique de choisir les GPIO en fonction de la position réelle des composants sur le PCB. Cela simplifierait fortement le routage, surtout avec seulement deux couches. -Cela veut dire que l'écran ne peut pas fonctionner à moins d'ajouter une alim 14V directement sur le circuit mais je n'ai pas pu essayer car j'avais peur qu'en branchant du 14V sur le chip qui laisse passer le 3.3V d'entrée puisse poser problème. +Il serait également intéressant de chercher un module LED unique capable de fournir environ 200 W. Je n'en ai pas trouvé chez les distributeurs classiques, mais certains modules existent sur AliExpress. Comme une future V3 serait réalisée hors du cadre strict du cours, il serait possible de commander plus librement les composants. -3. Le potentiomètre n'est pas sur une pin analogique +Le BMS pourrait aussi devenir un projet plus complet. Plutôt que d'être seulement une fonction de protection, il pourrait intégrer un écran, une mesure détaillée de l'état de la batterie, la gestion de la décharge et la gestion de la charge. -Le RP2040 est vraiment fantastique car il permet de rerouter nimporte quelle pin sur nimporte quelle autre pin SAUF les analogiques. Et j'ai eu la merveilleuse idée d'oublier que le potentiomètre en avait besoin... *facepalm* +L'utilisation de l'USB Power Delivery serait aussi intéressante. Une lampe de 100 W alimentée directement en USB-C serait pratique, et un BMS capable de charger la batterie depuis une alimentation USB-C éviterait d'utiliser un chargeur spécifique. -4. Parfois les drivers de leds explosent +Une autre piste est de revoir l'architecture batterie. Une tension 6S serait plus pratique qu'une batterie autour de 48 V. Elle serait plus proche des batteries utilisées en drone, plus facile à charger et probablement plus simple à manipuler. -Alors ! C'est un problème que j'ai rencontré très tard dans les tests et je ne sais pas encore comment exactement le reproduire pour isoler la cause. J'en reparlerai dans les tests mais une fois j'ai envoyé d'un coup la puissance max et ca a fait pêter un des drivers que j'ai du remplacer. Je ne sais pas si c'est à cause de mon layout, si c'est à cause de mon choix de capacitance, de mes drivers eux même ou si c'est simplement le problème de mon protocole de test qui était trop horrible ou juste que les drivers surchauffent +Enfin, il faudra prévoir des lunettes de protection adaptées. La puissance lumineuse du système est suffisante pour rendre les tests inconfortables, voire dangereux pour les yeux. -5. Sûrement d'autres choses +Un PCB noir serait aussi intéressant pour l'aspect esthétique, même si ce point n'a pas d'impact technique direct. -En fait je n'ai pas eu le temps de tester toutes les features de la carte et je suis sûr qu'il y a certaines choses qui pourraient être améliorées mais dans son utilisation principale j'ai tout mentionné. +== Conclusion -Il se trouve que cette seconde itération, bien que risquée vu qu'elle introduit pleins de nouveaux composants et en change pleins d'autre, est plutôt réussie ! En effet j'ai beaucoup moins de problèmes et la carte est bien plus utilisable que sa grande soeur et clairement il y a une grande amélioration sur presque tous les points. J'en suis donc plutôt content. - -=== Tests de puissance - -L'alimentation de labo classique ne permet pas de tester la carte à pleine puissance, j'en ai donc une autre qui peut le faire mais je n'ai testé le système à pleine puissance que quelques fois pour des durées plutôt courtes par peur de brûler mon circuit avant la présentation car la quantité de chaleur et de lumière que génère cette carte est véritablement effrayant. - -J'ai pu utiliser un thermometre pour mesurer la température de surface des leds et des drivers de leds. - -L'installation actuelle est très peu optimale. Les leds ne sont pas vraiment collées, elles tiennent avec l'adherance de la pâte thermique de pc et en plus cette même pâte thermique a une resistance thermique trop élevée. Dans l'idéal on devrait utiliser une epoxy thermique pour les fixer au radiateur, mais je n'etais pas sûr du layout des leds jusqu'à très récemment. Un ventilateur est utilisé et branché au PCB mais les tests se font sur une table et donc il ne peut pas fonctionner efficacement à moins que je le tienne en l'air. - -La première chose à noter c'est que la puissance lumineuse est assez indescriptible avec des images ou des môts. C'est éblouissant même à quelques dixaines de watts et la chaleur que ca génère quand on mets sa main dans le rayon de lumière est inquiètant. - -C'est assez difficile de faire des tests sans se faire des énormes tâches dans la vision et sans se brûler en essayant d'utiliser le themomètre. - -Autour des 80W on peut laisser les LEDS allumées pendant plusieurs minutes sans le moindre problème, leur température monte dans les 70 degrés mais ne monte pas ou très lentement après. Les drivers de leds restent dans les 35 degrés et je pense qu'une partie de cette chaleur vient du rayonnement de lumière des leds. - -Au dela de 120-150W on peut voir la temperature des leds monter rapidement à 70 degrés. Ensuite l'augmentation ralentis très fortement mais glisse petit à petit vers les 80 degrés qui est le moment ou j'arrête le test pour éviter d'endommager les leds. - -C'est assez impressionnant de voir que à 70 degrés la chaleur se transmet bien dans le radiateur mais simplement pas assez vite. Avec une epoxy je pense que ca aurait suffit. - -plus de tests au 200W vont arriver très vite mais le temps a clairement été contre moi avec mon envie de faire 2 versions du PCB - - -=== Choses à améliorer pour une V3 - -Il faut absolument que j'ajoute des thermistances SMD autour des drivers pour avoir une idée de leur température et pouvoir réduire leur puissance dans le cas ou il surchaufferaient. - -Je dois aussi absolument ajouter un moyen de mettre des thermistances sur les leds et les lire depuis le PCB car dans la situation actuelle je pourrais cramer les leds il n'y a aucune sécurité - -Je dois aussi maintenant prévoir comment vraiment agencer une case en 3D autour de la carte. Si j'arrive à faire une V3 aussi compacte que la V2 ca ne devrait pas poser de soucis vu que la carte est plus petite que le radiateur (la V1 en revance dépasse de partout) - -Je pourrais utiliser une version du radiateur plus baleze. le constructeur du radiateur actuel fait une version plus grosse : - -#figure( - grid( - columns: 2, // 2 means 2 auto-sized columns - gutter: 2mm, // space between columns - image("/assets/A53.png", width: 100%), - image("/assets/A53_2.png", width: 100%), - ), - caption: "Utilisation des GPIO sur les deux versions du PCB" -) - -=== Conclusion +Ce projet m'a permis de progresser fortement en conception de PCB, en soudure et en réparation. Les deux versions ont présenté de nombreux problèmes, mais chaque erreur a permis de mieux comprendre les contraintes réelles d'un système de puissance. +Ce semestre a été l'une des périodes les plus formatrices de ma formation. La possibilité de concevoir un circuit, de le fabriquer, de faire des erreurs, de les réparer et d'en comprendre les causes rend les apprentissages beaucoup plus concrets. +J'ai beaucoup apprécié ce cours et la liberté donnée dans le choix du projet. J'y ai consacré beaucoup de temps, mais cela m'a permis de progresser rapidement et de confirmer mon intérêt pour la conception de PCB. +Le projet aura probablement une V3 après une campagne de tests plus complète sur la V2. Les axes d'amélioration sont maintenant beaucoup plus clairs : sécurité thermique, alimentation, intégration mécanique, choix de batterie et fiabilité des drivers. +Je remercie les enseignants pour ce cours, pour l'encadrement et pour la liberté accordée, qui ont rendu ce projet particulièrement intéressant et formateur.