#set text(lang: "fr") #set par(justify: true) #set heading(numbering: "1.") #let deux-images(a, b, legende) = figure( grid( columns: 2, gutter: 2mm, image(a, width: 100%), image(b, width: 100%), ), caption: legende, ) #align(center)[ #text(size: 20pt, weight: "bold")[Projet de semestre CSH] #v(0.4em) #text(size: 16pt, weight: "bold")[Lumière vidéo bicolore de 200 W] ] #v(1em) 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. == Présentation du projet 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. 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. 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 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. == Contraintes du projet Pour respecter le cahier des charges du cours, le projet doit intégrer les éléments suivants : + 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. 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 === LED Mfr nbr : CTM-22-4018-90-36-TWD6-F3-3 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. 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 issue de la datasheet, avec les dimensions du module LED.], ) 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. Pour atteindre 200 W, il faut donc utiliser quatre modules LED. 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 de cette puissance, la gestion thermique est un point critique du projet. 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. En considérant une température ambiante de 30 °C, le budget thermique disponible est donc d'environ 55 °C. 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. 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 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( image("/assets/Noctua_rad.png", width: 50%), caption: [Radiateur Noctua réputé pour ses bonnes performances.], ) 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. 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. 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. 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/radiateur.png", width: 50%), caption: [Dynatron A51.], ) 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. Sa surface de contact est également plus adaptée : #figure( image("/assets/radiateur_specs.png", width: 50%), caption: [Dimensions du Dynatron A51.], ) 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. 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 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 : + utiliser un ventilateur 48 V ; + utiliser un ventilateur 12 V avec une alimentation dédiée. 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. 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é. 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. 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.], ) Lien Digitec : https://www.digitec.ch/fr/s1/product/noctua-ventilateur-nf-p12-redux-1700-pwm-120-mm-1-x-ventilateur-pc-12826297 === Batterie 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 === Microcontrôleur Le microcontrôleur est le centre de contrôle du circuit. J'ai choisi le RP2040. Mfr nbr : SC0914(13) Mouser nbr : 358-SC091413 #figure( image("/assets/RP2040_schem.png", width: 50%), caption: [Schéma du RP2040.], ) 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 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 de nombreuses recommandations pour intégrer correctement le RP2040 dans un design. Cependant, ce microcontrôleur demande plusieurs composants externes pour fonctionner correctement. ==== Composants associés au RP2040 #figure( image("/assets/RP2040_components.png", width: 50%), caption: [Schéma de la mémoire flash et du quartz.], ) Contrairement à certains microcontrôleurs qui intègrent davantage d'éléments en interne, le RP2040 nécessite plusieurs composants externes : + 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 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. 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 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 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 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 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 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( image("/assets/psu_autoswitch.png", width: 50%), caption: [Circuit de commutation automatique des alimentations 3,3 V.], ) Cette fonction évite de devoir brancher la batterie pour déboguer le firmware ou naviguer dans les menus de la lampe. 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.], ) 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, 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 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 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. Pour éviter ce problème, il a fallu isoler le bus I2C ainsi que la broche ALERT entre le BMS et le microcontrôleur. La broche ALERT est isolée avec un optocoupleur simple. Pour le bus I2C, j'ai utilisé un circuit spécialisé d'isolation. 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 #figure( image("/assets/ihm.png", width: 100%), caption: [Interface homme-machine de la V2.], ) La carte peut être contrôlée avec plusieurs éléments : + 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, 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: [Schéma de l'écran.], ) === Connecteurs et pinout #figure( image("/assets/connecteurs.png", width: 100%), caption: [Connecteurs et points d'accès du circuit.], ) Plusieurs connecteurs et pads permettent d'interagir avec les différentes cartes, avec l'extérieur et avec les points de debug. Les connexions les plus importantes sont les pads de batterie et les pads de connexion des LED. 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. La communication entre le PCB principal et la carte d'IHM passe par des connecteurs de type écran à 20 broches. Le ventilateur utilise un connecteur Molex standard pour ventilateur PC 12 V. 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. 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. 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 #deux-images("/assets/GPIO_V1.png", "/assets/GPIO_V2.png", [Utilisation des GPIO sur les deux versions du PCB.]) 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 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, 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 rencontrés === 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( image("/assets/GodDidNotExcpectThat.jpeg", width: 60%), caption: [Réparation manuelle du footprint de la mémoire flash.], ) 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. Après cette correction, il a été possible de programmer le RP2040 et d'exécuter du code. 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. === Petits problèmes de la V1 Les autres problèmes identifiés sur la V1 sont les suivants : + 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. 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. === Bilan de la V1 Sur cette première version, il y a clairement pas mal de pétouilles. Certaines sont petites, d'autres beaucoup moins, mais la majorité ont pu être contournées avec des réparations de fortune. Au final, la carte a quand même réussi à fonctionner en grande partie, ce qui est déjà une petite victoire. Les deux fonctions qui lui manquent vraiment sont le rail 12 V pour le ventilateur et le BMS. Le reste a soit fonctionné directement, soit pu être sauvé avec des corrections parfois assez moches, mais efficaces. En soi, la V1 n'est donc pas un échec. C'est même sur cette carte que presque tous les tests ont été réalisés, car la V2 est arrivée tard dans le développement et ses propres problèmes ont pris beaucoup de temps à régler. La V2 n'existe pas parce que la V1 était inutilisable, mais parce qu'elle permettait de corriger les défauts identifiés et d'ajouter de nouvelles fonctions. === Montage du PCB V2 #deux-images("/assets/PCB_2.jpeg", "/assets/PCB_2_ASSEMBLED.jpeg", [Réception et montage du second PCB.]) 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, patatra : rien ne fonctionnait. === 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/PCB_2_REPAIR.jpeg", width: 40%), caption: [Remplacement du microcontrôleur à l'air chaud.], ) 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. 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. 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. 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. Une fois le nouveau composant 3,3 V et la nouvelle flash installés, le rail 3,3 V était à nouveau à 5 V. Là, je ne vais pas mentir : l'ambiance était au plus bas. Je venais potentiellement de re-cramer les mêmes composants, alors que je pensais avoir corrigé le problème. L'erreur était en fait plus bête et plus violente que prévu : le composant choisi n'était pas seulement une version de sortie incorrecte, c'était un boost et non un buck. En gros, je m'étais concentré sur la tension de sortie en voyant une version 3,3 V compatible, mais j'avais raté le point le plus important : ce composant ne sait pas descendre une tension. 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. C'est une erreur franchement très bête, mais aussi très formatrice. Elle ne m'arrivera probablement plus jamais. Par contre, sur le moment, elle a endommagé un second RP2040 et une seconde mémoire flash, et il est peu probable qu'un remplacement direct par un buck compatible soit possible sans modifier le PCB. J'ai donc retiré le boost 3,3 V, remplacé à nouveau la mémoire flash et le microcontrôleur, puis alimenté la carte autrement. 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. 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. 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. 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. 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. Après remplacement par des résistances 0402, le RP2040 a enfin pu être programmé. 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. Après toutes ces réparations, la V2 est enfin devenue programmable et utilisable. Ouf. Cette phase a clairement demandé beaucoup de résilience. Les problèmes ont pris plusieurs semaines à être tous réglés, mais au final la carte fonctionne et chaque panne a permis d'identifier une vraie erreur de conception, de choix de composant ou de montage. === Problèmes restants de la V2 ==== Mauvais composant sur le rail 3,3 V USB 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. 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. 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. ==== Boost 14 V Le circuit 14 V est bien censé être un boost. Contrairement au rail 3,3 V USB, le principe est donc correct. 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. 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. ==== Potentiomètre connecté à une broche non analogique 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. J'ai donc eu la merveilleuse idée de connecter le potentiomètre à une broche qui n'est pas compatible avec l'ADC. Facepalm. Cette erreur empêche d'utiliser directement le potentiomètre tel que prévu. Elle devra être corrigée dans une future révision. ==== Défaillance de certains drivers de LED Un problème plus tardif concerne les drivers de LED. Lors d'un test, l'application brutale de la puissance maximale a fait exploser un des drivers, que j'ai ensuite dû remplacer. C'est le genre de problème qui fait un peu peur, parce que je ne sais pas encore le reproduire proprement. La cause exacte n'est pas connue. Plusieurs hypothèses restent possibles : + 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. Ce point devra être investigué plus précisément avant une V3. ==== Fonctions non testées 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. Malgré tout ça, cette seconde itération est plutôt réussie. Elle était risquée, parce qu'elle introduisait beaucoup de nouveaux composants et changeait plusieurs choix importants, mais elle est plus compacte, plus utilisable et meilleure que sa grande sœur sur presque tous les points. J'en suis donc quand même assez content. == Tests de puissance 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. 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. Les mesures ont été réalisées avec un thermomètre afin d'estimer la température de surface des LED et des drivers. 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. 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. 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. 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. 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. 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. 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. == Améliorations possibles pour une V3 Plusieurs améliorations sont nécessaires pour une future version. 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. 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. 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. Une option serait d'utiliser un radiateur plus performant de la même famille, comme le Dynatron A53. #deux-images("/assets/A53.png", "/assets/A53_2.png", [Dynatron A53.]) 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. 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. 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. 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. 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. 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. 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. 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. En résumé : il faut que j'achète des lunettes de soudure pour arrêter de me rendre aveugle. Un PCB noir serait aussi intéressant, parce que ce n'est pas très scientifique comme amélioration, mais c'est quand même trop la classe. == Conclusion Pour conclure, je dirais que je suis devenu beaucoup plus fort en conception de PCB, mais surtout en soudure et en réparation, vu la quantité phénoménale de problèmes que j'ai rencontrés sur ces deux versions. Ce n'était pas toujours agréable sur le moment, mais c'est probablement ce qui m'a le plus fait progresser. Je dirais aussi que ce sont les trois mois où j'ai le plus appris à l'HEPIA. Concevoir une carte, la recevoir, la monter, voir qu'elle ne fonctionne pas, comprendre pourquoi, la réparer, puis recommencer avec une meilleure version est une manière extrêmement efficace d'apprendre. Les erreurs restent beaucoup mieux en tête quand elles ont coûté plusieurs soirées de debug et quelques composants cramés. J'ai énormément apprécié ce cours. J'y ai passé une quantité absurde d'heures, mais c'est justement parce que la liberté donnée rendait le projet motivant. Je vais clairement continuer à faire des PCB après ce semestre. Je pense que ce projet aura 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 chaleureusement les enseignants pour ce cours, pour l'encadrement et pour la liberté accordée. C'est cette liberté qui a rendu ces mois de travail aussi difficiles, mais aussi aussi intéressants et formateurs.