= Projet de semestre CSH

= Lumière vidéo 200W bicolore

Ceci est le rapport de mon second projet PCB.

== Qu'est ce que c'est

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.

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.

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.

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.

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.

== Contraintes

Pour que le projet rentre dans le cahier des charges du cours il faut implémenter :

- Un MCU
- Une interface homme machine physique (boutons ecrans speakers etc.)
- Une commuication (I2C, SPI etc.) avec un capteur ou composant.

Dans notre cas, on ne devrait pas avoir de soucis à faire rentrer ces contraintes dans le projet.

Avec ce nouveau projet on a aussi plus de possibilités. *Si le projet les justifient* on peut par exemple :

- 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

(Possibilités à faire valider par les profs évidemment)

== Choix des composants externes

=== Leds

Mfr nbr: CTM-22-4018-90-36-TWD6-F3-3

Mouser nbr: 896-CTM224189036TWD6

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 :

#figure(
  image("/assets/LED.png", width: 50%),
  caption: [Image prise de la datasheet avec mesures de la 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.

Il faut donc 4 leds pour arriver aux 200W.

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.

=== 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.

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 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.

Pour le radiateur on a donc le droit à 36 degrés de budget et donc 36.5 /160 = à peu près 0.22.

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.

==== 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.

#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"
)

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.

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.

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.

Et même si on va dans les radiateurs vraiment balèzes comme :

#figure(
  image("/assets/Noctua_rad.png", width:50%),
  caption: [Radiateur Noctua réputé pour être très performant],
)

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...

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

#figure(
  image("/assets/radiateur.png", width:50%),
  caption: [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 :

#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.

==== Ventilateur

Ici le choix est asez vite fait. 

J'avais deux options de classe de ventilateur comme la tension nominale de ma batterie est de 48V.

+ Un ventilateur 48V "plug and play"
+ Un ventilateur 12V qui demande de l'électronique supplémentaire

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.

+ 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 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.

#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 

WIP

== Choix des composants du circuit

=== MCU

C'est le cerveau de notre circuit. J'ai choisi le RP2040

Mfr nbr : SC0914(13)
Mouser nbr : 358-SC091413

#figure(
  image("/assets/RP2040_schem.png", width:50%),
  caption: [Schematic 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.

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.

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.

Cependant, ce MCU demand un certain nombre de composants accessoires pour bien fonctionner.

==== Composants accessoires

#figure(
  image("/assets/RP2040_components.png", width:50%),
  caption: [Schematic de la flash et du crystal],
)

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 :

+ Des capa de découplage
+ Des switchs de reset et de bootsel
+ Une flash
+ Un oscillateur
+ Une entrée USB pour flasher 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 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.

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

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.

Pour l'oscillateur j'ai choisi le même que celui utilisé avec les raspberry pico.

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-.

=== Drivers de LEDS

#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"
)

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)

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.

=== BMS

#figure(
  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.

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.

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.

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.

Il a donc fallu isoler le bus I2C et la pin Alert entre BMS et MCU.

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. 

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.

=== Interface Homme Machine

#figure(
  image("/assets/ihm.png", width:100%),
  caption: [IHM de la V2],
)

Pour le contrôle de la carte il y a plusieurs options :

- 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)

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.

#figure(
  image("/assets/screen.png", width:100%),
  caption: [Schematic de l'écran],
)

=== Pinout

#figure(
  image("/assets/connecteurs.png", width:100%),
  caption: [Schematic de l'écran],
)

Pour la communication entre les trois cartes ou l'exterieur ou le debug on a plusieurs pins ou pads disponibles.

Les plus évidents sont les pads de batterie ainsi que les pads pour connecter les leds.

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.

Pour la communication entre le PCB principal et la carte IHM, on a des connecteurs style connecteur d'écran de 20pins.

Pour le ventilateur on a aussi un connecteur MOLEX qui est standart pour des ventilateurs 12V de PC classiques.

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. 

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.

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).

=== 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"
)

Ci-dessus, l'utilisation des pins du RP2040. C'est toujours utile de garder ce genre d'information pour la programmation du microcontrolleur.

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.

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.

=== Fabrication et problèmes 

==== Montage PCB 1

#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"
)

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.

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)

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).

Mais maintenant que on a un PCB monté on peut directement passer aux problèmes :)

==== Problèmes majeurs

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.

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)

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.

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.

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.

Avec le buck 12V desactivé, le circuit a pu être connecté à mon laptop en utilisant le port USB-C.

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é.

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.

Cela a été règlé de la manière la plus stressante pour les yeux de tous les temps :

#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é],
)

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.

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)

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.

==== Petits problèmes

Ici je vais parler des problèmes qui ne sont pas critiques en faisant une liste exhaustive.

+ 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

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.

==== Conclusion

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.

Les seules features qui lui manquent vraiment sont le 12V pour le ventilateur et un BMS.

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.

==== Montage PCB V2

#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"
)

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.

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.

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.

Et directment en branchant le circuit avec le port USB... patatra rien ne marche

==== Les peripéties (Pas obligé de lire)

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...

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 !!

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. 

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.

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.

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é

#figure(
  image("/assets/PCB_2_REPAIR.jpeg", width:40%),
  caption: [remplacement à l'air chaud du microcontrolleur],
)

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.

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.

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)

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.

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. 

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 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.

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.

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.

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.

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é.

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.

Donc après avoir remplacé le MCU avec un TROISIEME j'ai pu tout assembler et brancher sans que rien ne crame.

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.

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.

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... 

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.

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.

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-.

Mais toujours aucun signal sur mon laptop... la ca devenait vraiment pénible.

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. 

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.

Mais après un flash, impossible de le revoir apparaitre sur le laptop pour en mettre un autre...

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.

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.

==== Problèmes

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.

1. Le boost 5V qui devait être un buck 3.3V

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.

Sans ce problème aucunes des peripéties n'aurait eu lieu à part peut-être celle de l'USB C à replacer.

2. Le boost 14V

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)

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.

3. Le potentiomètre n'est pas sur une pin analogique

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*

4. Parfois les drivers de leds explosent 

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

5. Sûrement d'autres choses

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é.

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