diff --git a/.DS_Store b/.DS_Store index ad17ac1..0ce712e 100644 Binary files a/.DS_Store and b/.DS_Store differ diff --git a/Rapport/.DS_Store b/Rapport/.DS_Store index fab2f0e..1d8d75b 100644 Binary files a/Rapport/.DS_Store and b/Rapport/.DS_Store differ diff --git a/Rapport/Rapport.typ b/Rapport/Rapport.typ index eb87b43..6071948 100644 --- a/Rapport/Rapport.typ +++ b/Rapport/Rapport.typ @@ -217,49 +217,107 @@ 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 LED +=== Drivers de LEDS -Mfr nbr: ZXLD1366ET5TA +#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 -Pour driver ces leds il faut se concentrer sur les besoins des leds. Ces dernières ont besoin de : +Prix unitaire: 2,13 CHF tot: 17,04CHF -+ 34V à 37V mais normalement 36V -+ 700mA par canal avec un max à 850mA -+ Deux inputs différents pour contrôler la température de la couleur +Le driver de la V2 est le : -Un choix a été fait, une batterie de 13 cellules en série sera utilisée pour que même avec des cellules vides on reste correctement en dessus des 36V de la Led et que le driver n'aie que besoin de décendre la tension et aussi de ne pas demander trop d'ampères sur des cellules 18650 qui n'aiment pas en donner beaucoup. +mfr nbr: ALT80800KLPATR +mouser nbr: 250-ALT80800KLPATR -Mais une autre approche aurait été de partir d'une batterie avec moins de cellules en série et choisir un driver qui booste la tension au prix de plus de courant et une efficience peut-être inférieure. +Prix unitaire: 1,43 tot: 5,7CHF -L'option la plus simple avec ces contraintes serait de trouver deux drivers de leds qui peuvent chacuns driver les 100W de chaque canal de leds. Cependant je n'en ai pas trouvé et donc il a fallu passer sur la seconde option. +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. -La seconde option est d'avoir un driver par canal par led. 8 driver au total ce qui veut dire que chaque driver doit simplement gèrer 25W au grand maximum et donc 0.7mA. +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. -Pour cette option, le ZXLD1366ET5TA est donc parfait. Le seul inconvénient c'est que le package est petit et donc il pourrait chauffer facilement et cela multiplie par 4 le nombre de composants accessoires à utiliser et donc on prend beaucoup de place. +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 -Le coût de ce driver de leds se trouve surtout sur les composants dont il a besoin. Pour qu'il fonctionne correctement il a besoin de : - -+ Un gros capa de decouplage -+ Une grosse inductance -+ Une grosse diode -+ Une resistance de config -+ Un capa pour le soft start de la led - -Et pour driver le composant directement depuis le Rp2040 qui n'a pas de DAC intègré il faut des composants supplémentaires mais qui sont plus classiques. - -+ Un filtre passe-bas (capa + resistance) -+ Une resistance de pull-down pour eviter que les leds s'allument le temps que le MCU démarre. - -Pour les capa si c'était à refaire je pense que j'essaierais de trouver des options non electrolythiques même si c'est parfois difficile de trouver des options qui ne sont pas trop chères. - - +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], +) + +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. + +# A suivre diff --git a/Rapport/Tp2.typ b/Rapport/Tp2.typ index 58dd04b..d172f4f 100644 --- a/Rapport/Tp2.typ +++ b/Rapport/Tp2.typ @@ -530,7 +530,23 @@ Mouser number: 611-PTS636SKG25JSMTR === Ecran -Pour l'écran dans un premier temps on ne va pas trop s'embêter car le projet est déja assez complexe comme ca. Il y aura des GPIO disponibles en plus et je pense que l'écran ne sera pas une priorité +Pour l'écran j'ai trouvé un module qui ne coute pas trop cher et qui semble relativement simple à implémenter + +Mfr nbr: NHD-1.69-160128B +Mouser nbr : 763-NHD-1.69160128B + +On peut le configurer pour qu'il fonctionne en SPI ou en I2C ce qui permet de ne pas utiliser trop de GPIO + +Le connecteur à trouver est un connecteur : "Recommended FFC Connector: 30pin 0.5mm pitch" + +J'ai choisi celui la : + +Mfr nbr: AYF533035 +Mouser nbr: 769-AYF533035 + +Il permet de brancher l'écran dans un sens et dans l'autre ce qui est sympa. + + === USB C @@ -583,6 +599,11 @@ Dernière version de mon kicad : + Inversion des pins 5-7 de la flash (grossière erreur) + Mauvais choix de resistances pour le filtre PWM des drivers de leds (10k -> 1k) + Manque d'une pulldown de 4.7kR sur la pin ADJ des drivers de led pour ne pas laisser la pin flottante quand le MCU démarre ++ Le potentiometre est dans le mauvais sens... ++ Le BMS est inutilisable ++ Les trous pour les vis du radiateur ne sont pas parfaitement aux bons endroits + +La pin regSRC est marqué comme câblée sur batt+ mais ne peux pas gèrer plus que 25V donc l'alimentation avec du 50V a tué le chip. En plus les pins VC14 et VC15 sont très confuse à câbler et le choix de les laisser flotter n'est pas le bon. en plus on est pas obligé d'avoir les pins + ET - sur le BMS, j'aurais juste pu mettre la pin -. ==== Points généraux @@ -590,8 +611,22 @@ Dernière version de mon kicad : + Footprint du RP2040 qui force un PCB très cher chez eurocircuit + Design avec 8 drivers pénible et qui prend beaucoup de place (un design avec seulement deux drivers un peu plus chers mais qui peuvent encaisser les 100W chacuns serait bien plus idéal et pourrait potentiellement amener un PCB plus petit ce qui rembourserait le surcôut des drivers eux mêmes) + Buck 12V un peu archaique plutôt gros et qui demande des capa énormes donc une place disproportionnée pour son utilité sur le circuit - - ++ Pas de charge possible avec mon BMS ce qui est très chiant ++ L'architecture 13S est très pénible pour pleins de raisons et son seul intérêt est de réduire les ampères demandées au niveau de l'input batterie + +== V2 + + + + +J'aimerais trouver d'autres drivers de LEDS. Le but c'est de pouvoir réduire le nombre de drivers avec des composants plus robustes qui peuvent gèrer plus de courant. + +Cela permettrait de réduire la taille du PCB + +Mfr nbr: ALT80800KLPATR +Mouser nbr: 250-ALT80800KLPATR + +Ce driver est intéressant car on peut remplacer deux de mes anciens drivers avec un seul. Il n'est pas cher et je pense que on peut économiser beaucoup de place sur le PCB avec diff --git a/Rapport/assets/.DS_Store b/Rapport/assets/.DS_Store new file mode 100644 index 0000000..23c6e6e Binary files /dev/null and b/Rapport/assets/.DS_Store differ diff --git a/Rapport/assets/BMS.png b/Rapport/assets/BMS.png new file mode 100644 index 0000000..19a236a Binary files /dev/null and b/Rapport/assets/BMS.png differ diff --git a/Rapport/assets/BucksV1.png b/Rapport/assets/BucksV1.png new file mode 100644 index 0000000..eb6c942 Binary files /dev/null and b/Rapport/assets/BucksV1.png differ diff --git a/Rapport/assets/BucksV2.png b/Rapport/assets/BucksV2.png new file mode 100644 index 0000000..c527ce1 Binary files /dev/null and b/Rapport/assets/BucksV2.png differ diff --git a/Rapport/assets/SchematicV1.png b/Rapport/assets/SchematicV1.png new file mode 100644 index 0000000..c7b6956 Binary files /dev/null and b/Rapport/assets/SchematicV1.png differ diff --git a/Rapport/assets/SchematicV2.png b/Rapport/assets/SchematicV2.png new file mode 100644 index 0000000..f3c9b8a Binary files /dev/null and b/Rapport/assets/SchematicV2.png differ diff --git a/Rapport/assets/led_driver_V1.png b/Rapport/assets/led_driver_V1.png new file mode 100644 index 0000000..2d0bd60 Binary files /dev/null and b/Rapport/assets/led_driver_V1.png differ diff --git a/Rapport/assets/led_driver_V2.png b/Rapport/assets/led_driver_V2.png new file mode 100644 index 0000000..f32a75c Binary files /dev/null and b/Rapport/assets/led_driver_V2.png differ diff --git a/Rapport/assets/psu_autoswitch.png b/Rapport/assets/psu_autoswitch.png new file mode 100644 index 0000000..7d7c358 Binary files /dev/null and b/Rapport/assets/psu_autoswitch.png differ