L’ i-Kube est un boitier développé pour fêter les 7 ans de la guilde ICKA (MMORPG Dofus). C’est un cube qui illumine le logo ICKA. Il est alimenté soit par USB, soit par batterie, afin de pouvoir l’emmener partout !
Les lettres s’illuminent des 3 couleurs ; blanc, bleu et rouge du logo. La couleur noire est représentée par le boitier, imprimé en PLA noir. À l’intérieur, un PIC16 permet de commander un driver de PWM. Ce dernier s’occupe de piloter les LED. On retrouve également un BMS qui s’occupe de superviser la recharge de la batterie Li-ion.
Le développement
Alimentation
L’ i-Kube est principalement alimenté par sa batterie Li-ion de 3.6V et >2Ah, ce qui rend le cube portable avec une autonomie estimée entre 72 et 84h. Une alimentation +5V est disponible en µUSB afin de recharger la batterie, ou alors comme alimentation principale. La recharge et décharge de la batterie sont protégées par un fusible 1A. La sélection de l’alimentation s’effectue par 2 diodes Schottky à LDO, ce qui permet à l’USB, qui a une tension plus élevée, d’être prioritaire sur la batterie mais également, lorsque la batterie est seule, de ne pas alimenter le chargeur. Un cavalier permet, si besoin, d’isoler complètement et facilement la batterie, en la gardant branchée.
La commande
Le microcontrôleur est un PIC16F15225. Il communique avec un driver PWM PCA963X en I²C qui s’occupe de commander les 7 LED du logo (2x blanches, 2x bleues et 3x rouges). Deux commutateurs permettent soit de changer l’animation LED, soit d’afficher l’état de charge de la batterie sur 4 LED. Ces 4 LED se situent sur le côté et ne s’allument que lors de l’appui sur le commutateur de charge. Ces LED affichent brièvement le mode d’animation en binaire, à l’appui sur le commutateur de mode.
Réalisation
Le PCB a été conçu sous Altium Designer. Il s’agit d’un deux couches traditionnel, avec une finition ENiG RoHS. Le vernis épargne est en noir mat pour l’esthétique.
Le boitier a été conçu sur mesure sous SolidWorks et imprimé en PLA grâce à mon imprimante FDM.
BIL, “Boitier Interface LED”, est le premier projet que j’ai réalisé. Le principe est simple : pouvoir commander un ou plusieurs rubans LED RGB avec une application dédiée. Ce projet m’a permis l’acquisition méthodique de certaines compétences de programmation de microcontrôleur : le premier prototype, très simple, est basé sur Arduino IoT incluant déjà le module Wi-Fi alors qu’aujourd’hui la première version stable est équipée d’un PIC et d’un module Wi-Fi séparé, bien qu’issus du même fabricant. Le prototype BIL possède sa propre application mobile. Bientôt, suite à l’élargissement des fonctions de cette application, elle se dissocie du projet BIL et change de nom : Allotropy.
Le développement
Vue d’ensemble
Le boitier est composé de 2x PCBA : la PowerBoard embarquant la partie “puissance”, s’occupe de distribuer le +12V au ruban et de transformer le +12V en +3.3V. Ce +3.3V sert à la seconde carte, la CoreBoard qui s’occupe exclusivement du traitement et transit des data.
Le microcontrôleur sélectionné est un PIC24 (16bits) ; à côté on retrouve un module Wi-Fi ATWINC15xx et une EEPROM de chez Microchip. Ces éléments forment l’arbre principal de communication : l’EEPROM stocke les données que le PIC va transmettre via le module Wi-Fi à l’application.
Les rubans LED sont pilotés par un module PWM qui vient commander des MOSFET pour chaque couleur.
En accessoire, on retrouve un module d’extension I/O permettant de commander certaines LED qui indiquent différents états importants du boitier ou de récupérer certaines entrées secondaires. Un module dit “ui” est présent avec un écran OLED et un Bouton/LED, ce module permet un affichage des paramètres réseaux du boitier ainsi que des messages d’erreur pendant 30s à l’appui sur le bouton.
Alimentation
Le boitier est alimenté par une alimentation +12V, le courant dépendant de la longueur du ruban (7A pour 5m). Un interrupteur permet une commande hardware de la mise en marche. Derrière il y a un fusible de protection 5x20mm. Un régulateur de tension à découpage vient abaisser la tension en +3.3V pour alimenter la CoreBoard.
La commande
Le microcontrôleur, un PIC24FJ64GP202, communique avec l’application grâce à un ATWINC1510, un module Wi-Fi de chez Microchip. Ces deux C.I. communiquent en SPI. Lors de la réception de donnée de couleur, le PIC modifie les PWM, via le module dédié, qui commandent des transistors MOSFET qui commandent le ruban. Ce dernier est connecté via un connecteur Molex µFit 2×2. Tous les C.I. sont alimentés en +3.3V. Deux modules de commande de puissance permettent, pour l’un, d’éteindre physiquement le module Wi-Fi pour le redémarrer dans le cas ou le RESET ne fonctionne pas, pour l’autre d’éteindre l’afficheur OLED.
Le boitier a 3x variables d’états de prévues qui sont retranscrits à l’utilisateur par 3x LED :
Un état Host ou AP qui détermine l’état du système. En Host, le boitier est connecté à un réseau Wi-Fi et peut recevoir des data d’application. Si aucun réseau Wi-Fi n’a pu être atteint, alors on passe en mode AP (Access Point) et le boitier émet son propre réseau Wi-Fi. C’est alors le téléphone de l’utilisateur qui doit s’y connecter avec pour objectif de reconfigurer correctement le BIL pour pouvoir retourner en mode Host. Une LED bicolore permet d’informer l’utilisateur d’un mode ou l’autre. Tu me suis ?
Un état d’erreur si une erreur critique est survenue.
Un état Locked : les premiers essais de la version stable devront déterminer si ce mode est pertinent ou non, car ce mode est ici pour verrouiller d’une certaine manière la mémoire d’un BIL afin de prévenir le cas où plusieurs applications chercheraient à modifier un même paramètre en même temps.
La communication entre l’application et le BIL se fait exclusivement en réseau local. Pas de WAN.
Une extinction logiciel étant possible, une LED blanche vient donner un témoin On/Off.
EEPROM
Une mémoire EEPROM I²C permet de stocker la configuration et les informations du BIL. Cette mémoire stocke aussi bien le nom d’hôte et la version que l’adresse IP et les informations du Wi-Fi.
Surveillance de la température
Un capteur de température est présent et permet de récupérer la température du boitier pour éviter la détérioration des composants. Si le boitier atteint une température assez élevée, entrainant une température en interne plus chaude, un ventilateur viendra renouveler l’air.
Réalisation
Les PCB ont été conçus sous Altium Designer. Les deux circuits imprimés sont des deux couches traditionnels, avec une finition ENiG RoHS. La PowerBoard possède une épaisseur de cuivre de 70µm afin d’assurer une bonne résistance face au courant important requis par des rubans LED longs. La CoreBoard a une épaisseur plus classique de 35µm.
Le boitier a été conçu sur mesure sous SolidWorks et imprimé en PLA grâce à mon imprimante FDM.
Le PCBA et le boitier sont fixés par des vis, M2 ou M2.5, à l’aide d’inserts filetés insérés à chaud dans les pièces 3D.
L’application
L’application BIL en elle-même n’existant plus, si tu veux tout savoir je t’invite à aller consulter la page du projet Allotropy.
Allotropy (de allotrope, qui peut prendre plusieurs formes) est une application permettant de piloter les systèmes via une communication réseau (généralement Wi-Fi). Ce système est conçu pour être évolutif. Il comprend : un protocole d’encapsulation, une gestion de la mémoire du système et une application mobile.
Introduction
Allotropy est une application cross-platform développée sous Qt en C++ (basé sur QWidget). Grâce à ses différentes librairies, j’ai pu créer une application dynamique accordant un contrôle fluide et ergonomique des différents boitiers connectés. Les outils de déploiement Qt permettent de très facilement mettre en ligne l’application sur Android et iOS.
Structure
L’application est développée en C++ avec l’aide de QMainWindow et QWidget. Les différents éléments sont animés avec l’aide de QPropertyAnimation. Le style des widgets et les icones sont gérés par des classes dédiées favorisant une attribution facile pour chacun des widgets tout en contribuant à une permutation mode clair/sombre facilement et rapidement.
Fonctionnement
Au lancement, l’application tente de se connecter à tous les boitiers et affiche leurs états en conséquence. Des boutons permettent de connecter ou d’éteindre tous les boitiers. Si le téléphone est connecté au Wi-Fi émis par un boitier en mode AP (Acess-Point), alors l’application lance la configuration du boitier.
Chaque BIL possède ses boutons pour tenter une connexion, modifier la couleur, l’éteindre et accéder à ses informations (et les modifier si besoin).
La modification des couleurs s’effectue à l’aide de sliders, un pour chaque couleur rouge, vert et bleu permettant de faire varier chaque composante de couleur parmi 256 valeurs.
Les nouveaux BIL sont enregistrés dans un fichier de base de données SQLite avec leurs informations principales (nom d’hôte, version, adresse IP, couleur).
Lors d’une recherche pour ajouter un nouveau boitier, l’application scanne les boitiers sur le réseau et les propose à la connexion. Une interface de saisie manuelle des paramètres est également implémentée.
L’application inclut, comme chaque boitier, les librairies permettant d’encapsuler les data. Cette encapsulation ne correspond pas à l’encapsulation réseau. Il s’agit d’un moyen de gérer les data transmises entre l’application et les boitiers. Certains caractères ASCII définissent un type de donnée parmi 4x : un numéro de transmission, aléatoire, compris entre 000 et FFF (base 16), le type de données transmises, les données en question ainsi que le type d’opération ; lecture, écriture, acquittement, erreur, …
Vers le GitLab de la PowerBoard
