IMA4 2018/2019 P63
Sommaire
Présentation générale
Etudiants : Victor Lorthios, Juliette Obled
Encadrants : Alexandre Boé, Xavier Redon, Thomas Vantroys
Description
Ce projet consiste à modéliser la consommation d'un capteur de pollution.
Ce système sera composé d'un ATMEGA ainsi que d'un capteur de particules, un capteur de température/humidité, une carte SD et un système Bluetooth pour transmettre les données.
Objectifs
Dans un premier temps, nous allons travailler avec une carte Arduino afin de pouvoir facilement tester les différents capteur et commencer à étudier leur consommation en énergie. Nous allons ensuite réaliser un système embarqué composé d'un ATMEGA, des deux capteurs, d'un système de transmission de données bluetooth et d'un système stockage des données via une carte sd. Ainsi on aura un prototype composé uniquement des fonctionnalités nécessaire. Cela permettra de ne pas fausser nos mesures car l'Arduino comporte des ports et des fonctionnalités supplémentaires qui risqueraient de consommer plus que nécessaire.
Depuis ce capteur il faudra alors faire l'étude de la consommation énergétique des différents composants, en particulier celle du capteur de particules qui est en théorie la plus élevée.
Enfin, on pourra tester quelles sont les meilleures manières d'utiliser les composants pour trouver leur consommation d'énergie minimale (capteur en route, en veille ou éteint quand on ne l'utilise pas). Cela sera fonction de variables telle que la période entre la prise de données notamment. On étudiera notamment les différentes manières de mettre en veille un capteur, la consommation au redémarrage, etc.
Le but final est donc d'établir un modèle, pouvant déterminer à l'avance l'autonomie du circuit. L'Idéal étant d'avoir un système consommant le moins d'énergie possible.
Analyse du projet
Positionnement par rapport à l'existant
La pollution est un enjeu sanitaire majeur. En effet, les polluants atmosphériques sont à l'origine de nombreux décès en France et dans le monde (48000 victimes en France selon l'agence de santé publique).
Pour réduire et éviter les endroits où la pollution est la plus dense, il est très intéressant de pouvoir analyser la présence de ces particules fines.
Ces dernières années, de nombreux moyens ont été mis en oeuvre pour surveiller la pollution. On retrouve par exemple de nombreux objets connectés composés de capteurs capables de mesurer la qualité de l'air. Ces objets permettent notamment de sensibiliser la population à ce problème.
Analyse du premier concurrent
Flow est un objet de 12,5cm de haut et 4cm de large permettant d'analyser la pollution de l'air en temps réel. En appuyant sur un bouton, on peut relever la concentration des principaux polluants dans l'air.
Ce capteur est commercialisé par l'entreprise française Plume Labs, fondée en 2014 dans le but d'améliorer notre quotidien face à la pollution.
Le résultat s'affiche directement sur l'objet, par l'allumage de leds : une couleur sombre correspond à un taux de pollution élevé et une couleur claire un air sain. Les résultats peuvent également être transmis via bluetooth sur le téléphone afin d'être affichés sur l'application Air Report. Cette application est composée d'une carte permettant de géolocaliser le téléphone et ainsi représenter le taux de pollution de chaque endroit de la ville. Toutes les personnes utilisant Flow peuvent donc contribuer à améliorer cette carte. Ce capteur permet donc d'évaluer ses parcours dans la ville, et inciter les gens à passer par des endroits plus sains. Il est également utilisable dans la maison. L'application propose aussi des "bulletins météo" concernant la qualité de l'air des jours à venir et annoncer les pics de pollution.
Etant si petit, résistant (fait d'acier) et ne pesant que 70g, Flow est transportable partout. Le capteur se recharge facilement sur ordinateur ou secteur grâce à un câble USB-C vers USB, et est supposé avoir une autonomie de 24h.
Ce capteur est donc très avancé mais coûte tout de même 179euros.
Nous pouvons nous positionner par rapport à cet objet en espérant atteindre une fiabilité de nos mesures pour une autonomie supérieure à une journée, à moindre coût.
Analyse du second concurrent
Pollutrack est un système du mesure de pollution de l'air installé sur des véhicules électriques appartenants à Enedis. Il permet de mesurer la pollution près du trafic dans des grandes villes telles que Paris ou Lille. Plus de 300 capteurs mobiles Pollutrack sont utilisés en complément de stations qui mesurent en temps réel la quantité de particules nocives dans l'air. Le dispositif permet de récupérer un très grand nombre de mesures. Grâce à ces mesures, il est possible de comparer le niveau de pollution d'une rue à l'autre ,d'un quartier à l'autre et d'ainsi repérer les zones de concentration de la pollution.
Scénario d'usage du produit ou du concept envisagé
L'utilisation de ce capteur sera la suivante : on imagine une personne voulant évaluer le taux de pollution dans l'air à but professionnel ou non. Grâce à ce capteur connecté via Bluetooth sur le téléphone, les données peuvent être transmises à intervalle régulier, ou stockées sur la carte SD pour être envoyées plus tard (si problème de réseau ou autre).
L'utilisateur voulant faire de nombreuses mesures dans plusieurs zones géographiques, il a besoin que le capteur ait une consommation énergétique faible pour être utilisé le plus longtemps possible. On pourrait même penser à quelqu'un souhaitant réaliser une cartographie du taux de pollution d'une ville. Il a alors besoin de faire énormément de mesures (il peut les avoir en temps réel sur son téléphone) mais surtout de faire des relevés assez longtemps pour que la cartographie soit fiable (pas de mesures trop espacées dans le temps). D'où la nécessité d'avoir un système dont on connait la consommation énergétique.
Grâce à nos recherches, nous pourrons donc assurer l'autonomie de ce capteur simplifié.
Le capteur peut également être utilisé de manière fixe dans une usine par exemple, provoquant une alarme si la pollution dans l'air est trop élevée. Nos modélisations permettraient à l'entreprise de connaître combien de temps le capteur serait utilisable et donc estimer le moment de la journée le plus propice pour effectuer des mesures.
Réponse à la question difficile
- Quelle est la fréquence optimale de récupération des valeurs de particules en fonction des usages ?
le site https://www.airparif.asso.fr/ mesure et cartographie précisément la pollution de Paris et de son agglomération en temps réel.
L'ensemble de leurs données permettent de produire une carte avec au mieux une résolution de 10 mètres par mesure.
En prenant l'exemple d'un piéton marchant à la vitesse de 4 km/h il faudrait une mesure toutes les 9 secondes pour avoir une résolution de 10 mètres.
Si on prend le cas d'un cycliste roulant à la vitesse de 20km/h il faudrait une mesure toutes les deux secondes pour atteindre une résolution de 10m.
Dans le cas où le capteur serait fixe avec une mesure toutes les deux minutes paraît suffisante.
- Comment tester un maximum de configuration des différentes fonctions pour déterminer la consommation énergétique et estimer la durée de vie finale ?
Nous testerons les différentes configurations sur la carte Arduino. Cela nous permettra de pouvoir changer facilement les câblages (pas de soudures, etc).
Les tests se feront grâce au code d'un ancien thésard qui nous permettrons d'estimer la consommation énergétique du système.
Nous étudierons les possibilités suivantes
- Mise en veille du capteur (utilisation de la broche enable)
- Coupure de l'alimentation du capteur (utilisation d'un transistor pour commander l'état du capteur)
- Mode sleep du microcontrôleur
Une fois la meilleure configuration trouvée nous réaliserons la carte pour avoir la consommation exacte et ainsi pouvoir déterminer l'autonomie de la carte.
Préparation du projet
Cahier des charges
Etudiants : Victor Lorthios, Juliette Obled
Encadrants : Alexandre Boé, Xavier Redon, Thomas Vantroys
Éventuels Clients : personne lambda désireuse de connaître le taux pollution de l'air qu'elle respire
Sujet
Modéliser la consommation énergétique d'un capteur de pollution simplifié.
Objectifs
Dans un premier temps il faudra réaliser un capteur simplifié de pollution sur une Arduino, depuis différents composants (capteur d'humidité/température et capteur de particules). Depuis ce système on pourra alors récupérer le taux de pollution de l'air de manière périodique (grâce au module bluetooth et à la carte SD). Nous verrons alors le temps de réponse de notre système (si il est lent ou rapide à s'adapter dans un environnement instable, etc) pour en déduire sur quelle période de relevés se baser.
Dans un second temps, des configurations seront testées pour déterminer la meilleure manière - énergétiquement parlant - de relever le taux de pollution : Comme expliqué dans la question difficile, nous verrons notamment différents moyens de mettre en veille notre capteur entre les relevés.
Nous retiendrons alors la meilleure configuration à notre usage pour réaliser le capteur de pollution depuis un microcontrôleur, afin de limiter au mieux toute consommation énergétique superflue.
Enfin, nous pourrons étudier la réelle consommation de notre système et en tirer un modèle, afin d'être capable d'annoncer la "durer de vie" du capteur selon l'utilisation retenue.
Choix techniques : matériel et logiciel
Matériel nécessaire
Carte principale
- Carte Arduino UNO [1]
- ATMEGA328p [2]
- BreadBoard [3]
- Quartz de 16MHz [4]
- Capteur de température/humidité DHT11 [5]
- Carte SD 16Go [6]
- Shield Bluetooth [7]
- FTDI [8]
- Module USB [9]
- Résistances : 1*1MOhm + 2*10kOhm + 4*1kOhm
- MicroSD card module [10]
- 1 Transistor Mosfet IRF530NPBF [11]
- 4 Résistances CMS 1KOhm [12]
- 3 Résistances CMS 10KOhm [13]
- 1 Résistance CMS 4,7KOhm (0805 !) [14]
- 1 Résistance CMS 1MOhm [15]
- 8 Capa0603 CMS 0.1uF [16]
- 2 Capa0805 CMS 22pF [17]
- 1 Capa0805 CMS 10uF [18]
- 1 Diode verte CMS 0603 [19]
- 1 Diode rouge CMS 0603 [20]
- Régulateur 5v/3.3v [21]
- Bouton poussoir
- 3 Capteur de particules PM2.5 - SEN0177 (avec son adaptateur) (un déjà eu) [22]
Pourquoi 3 capteurs : pour les tests de mise en veille, il nous faut 1 capteur test, et 2 capteurs de référence (car souvent beaucoup de variation de valeurs entre les capteurs)
Carte secondaire
- 2 AOP LTC6800 [23]
- Header
- 2 Capa0603 CMS 0.1uF
- 2 Résistance CMS 1206 10 Ohm
- 1 Résistance CMS 0603 10k Ohm
- 1 Résistance CMS 0603 27k Ohm
Logiciels
Nous utiliserons le logiciel IDE Arduino pour le code de l'arduino et Altium pour réaliser notre carte électronique
Liste des tâches à effectuer
Capteur de pollution depuis une Arduino
- correctement câbler les composants
- écrire un code pour en retirer des valeurs correspondants à un taux de pollution
- récupérer ces valeurs depuis 1) la carte SD 2) le module bluetooth
Etudes des valeurs reçues
- déduire des valeurs reçues des courbes correspondant au taux de pollution dans l'air en fonction du temps (notamment en environnement instable où l'on change brutalement le taux de particules dans l'air)
- déterminer depuis ces courbes et depuis nos espérances (de la question difficile n°1) une période pour relever le taux de pollution
Tests de différentes configurations
Comme il est important de minimiser la consommation énergétique de notre système, nous rechercherons une mise en veille optimale de notre système, sans que cela ne gène le relevé.
Nous testerons donc différentes configurations comme expliqué à la question difficile n°2.
- mise en veille du capteur (utilisation de la broche enable)
- coupure de l'alimentation du capteur (utilisation d'un transistor)
- mode sleep du microcontrôleur
Système optimisé
Conscient que l'arduino peut consommer plus que seulement ce dont les capteurs auraient besoin, nous allons dans une deuxième partie réaliser le système depuis un ATMEGA avec la configuration retenue.
- réalisation de la carte électronique
- code et essais pour étudier la cohérence des relevés par rapport aux anciens
Modélisation de la consommation finale de notre système
Depuis le programme d'un thésard polytech, de la même manière que pour les tests de mise en veille, nous étudierons la consommation de notre capteur pour en tirer un modèle et ainsi déterminer combien de temps il peut être utilisé.
Pour aller plus loin
Si jamais nous réussissons à faire toutes ces tâches avec succès, pourquoi pas tester une autre utilisation (automobiliste, etc) avec donc une autre période pour les relevés et peut-être une autre configuration pour la mise en veille.
Il pourrait également être intéressant de réussir à se géolocaliser pour plus facilement exploiter les données de ce capteur simplifié.
Calendrier prévisionnel
Réalisation du Projet
Feuille d'heures
| Tâche | Prélude | Heures S1 | Heures S2 | Heures S3 | Heures S4 | Heures S5 | Heures S6 | Heures S7 | Heures S8 | Heures S9 | Heures S10 | Total |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Analyse du projet | 0 |
Semaine 1
Lors de ces premières séances, nous avons commencé à réaliser le PCB sur Altium de la carte représentant notre capteur de pollution. Au cours de ce travail, nous nous sommes donc rendus compte qu'il fallait revoir notre liste de matériel, qui est incomplète. Nous aimerions finir le schéma électrique des capteurs associés à l'Arduino ainsi que la représentation Altium du microcontrôleur avec les autres composants d'ici les prochaines séances, afin d'avoir rapidement une liste de matériel fixe et éventuellement pouvoir demander une vérification de notre schéma Altium pour ensuite démarrer la partie Routage de la carte.
Nous avons également trouvé du code disponible pour l'utilisation des capteurs.
Semaine 2
Une grosse partie du schematic a été terminée.
Il comporte un atmega328p. Pour son bon fonctionnement, il possède un reset, un quartz et un module ICSP. Pour ce faire, nous avons utilisé le schematic d'une Arduino UNO disponible sur le site d'Arduino.
Il est connecté à un FTDI FT232RL pour pouvoir téléverser facilement le code depuis l'ordinateur sans avoir besoin d'utiliser un atmega16u2. Il y a donc avec ce FTDI un module USB. Nous nous sommes inspirés de ce site pour câbler correctement notre circuit.
Enfin, nous avons ajouté des header correspondant respectivement au capteur de particules et au capteur de température/humidité. Comme on peut le constater sur la capture d'écran ci-dessous, le capteur de particules est connecté à un transistor. Cela nous servira pour pouvoir commander la mise en veille du capteur.
Nous avons décidé des valeurs de résistance et de capacité selon les datasheet des modules et selon les calculs ci-contre.
Il nous reste maintenant à inclure un module bluetooth et SD pour que notre capteur soit complet. Nous devons également voir avec un des encadrants l'utilisation du capteur de particules. En effet, ce capteur peut donner de grandes variations de valeurs, d'où la nécessité d'utiliser plusieurs capteurs (nous en avons demandé 3) pour avoir une valeur moyenne. Ainsi, nous devons discuter de la mise en place d'un ou de trois transistors pour notre utilisation.
Nous avons également demandé une license Altium pour la suite de ce projet.
L'objectif de la semaine prochaine est donc de discuter avec nos encadrants pour finaliser notre schematic, et alors commencer la partie routage.
Semaine 3
Nous avons amélioré et adapté notre schématic aux contraintes vues avec M. BOE. Dans le but de mesurer le courant, nous avons donc ajouté des header à chaque composant. Nous avons également décidé d'utiliser un MOSFET pour la commande du capteur de particules (plutôt qu'un NPN précédemment). Enfin, nous avons terminé d'ajouter tous les composants (module bluetooth et connecteur de carte sd) à notre circuit.
La partie routage est en cours, ainsi que la création d'un autre schématic dans l'optique d'avoir un circuit additionnel permettant de mesurer facilement la tension utilisée par les composants.
Semaine 4 à 7
Nous avons continué à travailler sur notre schématique. De nombreux problèmes sont survenus petit à petit d'où l'absence de résultats intermédiaires.
Nous avons également avancé sur un deuxième schématique, une deuxième carte que nous utiliserons pour effectuer les mesures de puissance utilisée des composants. Nous devons encore en discuter avec M. BOE.
De plus, nous avons commencé à travailler sur le code des capteurs.
Semaine 7
- Partie Electronique
Le routage de la carte électronique est terminé. Il y a eu un certain nombre de modifications sur le schématique, dues aux différentes difficultés survenues lors de ce routage. Nous avons notamment changé la quasi totalité des empreintes, adapté les header, ajouté des capacité de découplage ou encore modifié la référence de certains composants.
De ce fait, la liste de matériel est à jour. Nous avons également pu voir avec M. Flamen pour récupérer gratuitement une grande partie des composants nécessaires (résistances, capacités,
La prochaine étape est donc de résoudre les éventuelles erreurs lors de la génération de la carte et commencer sa fabrication.
Nous avons également en cours la deuxième carte qui est encore au stade du schématique, en attente de retours.
- Partie Arduino
Pour commencer, le code du capteur DHT22 (température et humidité) est terminé. Nous avons simplement récupéré un code sur internet. On peut voir sur la capture ci-contre la différence en environnement "normal" et lorsque l'on souffle sur le capteur (augmentation du taux d'humidité)
Nous avons également travaillé sur le capteur PM2.5 (particules fines). Pour celui là nous établissons le code petit à petit.
Pour récupérer les données transmise par le capteur, nous avons utilisé la fonction arduino "SoftwareSerial" qui nous permet de de créer une liaison série sur d'autres pins de la carte arduino. Ainsi lors de l'affichage sur le moniteur série, il n'y aura pas de conflits.
Dans un premier temps, nous avons affiché la trame telle qu'elle est et avons identifié les octets grâce à la documentation ci-contre.
Le "32" au dessus du message correspond à la taille du message reçu. Cela sert notamment à savoir s'il est en fonctionnement. Les encadrés correspondent aux données auxquelles nous nous intéressons.
Nous avons ensuite réalisé des tests pour être sûrs que le capteur fonctionne correctement. A l'aide d'une brosse pleine de craie, nous avons donc fait tomber de la poussière ce qui a donné les résultats ci-contre à gauche.
Nous avons ensuite connecté une broche de l'arduino à la pin SLEEP du capteur pour contrôler sa mise en veille, pour pouvoir simultanément contrôler la mise en veille du capteur et la récupération/affichage des données reçues, nous avons utilisé la fonction millis qui récupère temps écoulé. Contrairement à delay, c'est une fonction non bloquante.
On voit que le capteur est n'est plus actif grâce au premier chiffre qui correspond à la taille de la trame ( c'est valeur de retour de la fonction "PMSerial.readBytes"; quand elle vaut 0 cela indique qu'aucunes données ne sont transmises) : les données affichées sont les dernières étant stockées, le 0 nous permet de savoir qu'en réalité nous n'avons reçu aucune nouvelle donnée du PM2.5
Semaine 8
- Partie Electrique
Nous avons effectué quelques changements au niveau de la partie MOSFET, qui n'était précédemment pas correcte. Nous avons alors le schématique et le PCB ci-contre.
Nous avons également terminé le deuxième circuit permettant de mesurer la valeur du courant passant dans nos capteurs. En connectant les headers de notre circuit principal au header 80, nous allons pouvoir lire la valeur du courant sur le header 90. Nous nous sommes inspirés de la datasheet LTC6800 pour réaliser ce circuit. Le schématique et PCB associé sont ci-contre.
Nous attendons maintenant une validation de ces deux circuits pour lancer la réalisation.
- Partie Arduino
Nous avons beaucoup avancé sur la partie Arduino.
Dans un premier temps, nous avons adapté la récupération de nos données en n'affichant que les données voulues, c'est-à-dire les taux de particules et plus les variables check.
Ceci nous donne le code ainsi que les réceptions ci-dessous. Nous avons également ajouté le fait que lorsque la trame est vide (length = 0 vu précédemment) nous n'affichons rien.
Les fonctions get_pm_** permettent de séparer les données correspondant à chaque particules. Nous récupérons simplement la donnée à son indice, et si elle est composée de deux - ou plus - octets (et donc deux places dans la trame) alors nous décalons la première valeur de 8 bits afin d'obtenir le taux correspondant. Nous l'affichons ensuite avec un simple Serial.Print.
Ensuite, nous avons ajouté le MOSFET que nous avons reçu. Après quelques vérifications, nous avons modifié le schématique comme dit plus tôt. En associant une pin à ce transistor, (ici la pin 13) il joue le rôle d'interrupteur : en envoyant 1 le capteur est correctement alimenté, et en envoyant 0 le capteur est alors éteint électriquement. Nous avons effectué les mêmes tests que la semaine dernière avec la veille du capteur, en utilisant la fonction millis (présente sur la capture du code), ce qui fonctionne bien comme en témoigne la led du capteur PM2.5 qui s'éteint ou s'allume toutes les 10 secondes. On est donc bien capable de piloter électriquement le capteur grâce au transistor.
Nous avons enfin ajouté le shield bluetooth (on l'alimente simplement avec la carte Arduino et on connecte respectivement les pins Rx,Tx du HC-05 sur les pins Tx,Rx de l'Arduino), et installé une application sur notre téléphone. Grace à une application sur le smartphone on est capable de ce connecter au HC-05 et correctement recevoir les données.
Semaine 9
Nous avons cette semaine terminée la carte principale grâce aux conseils de M. Flamen, M. Boe et M. Redon. Elle est en production chez Elecrow Bazaar, c'est donc notre version finale. Une fois reçue, nous pourrons y souder les composants.
Au niveau du schématique, nous avons ajouté un régulateur 5V/3.3V pour alimenter le connecteur de carte SD. Au niveau du PCB, nous avons fait un plan de masse digne de ce nom, adapté les pistes en évitant les petits angles, déplacé certains composants pour avoir des zones de masses continues, et délimité une zone blanche (keep out) sous le quartz. Nous avons également mis les composants traversants sur la couche bottom, mis en place les couches overlay, défini la couche mechanical et fait attention au Design Rule Check.
Semaine 10
Nous avons pu imprimer avec M. Flamen la carte secondaire. Nous attendons l'arrivée du LTC6800 pour pouvoir souder la carte.
Nous avons également travaillé sur le calcul de la résistance en entrée du LTC6800. En effet, sa valeur dépend du composant pour lequel on va mesurer le courant.
Après quelques recherches, nous avons pu trouver les valeurs de courant suivantes : ~120mA pour le PM2.5, entre 1 et 15 mA pour le DHT22 et entre 15 et 60 mA pour le HC-05. On a donc une plage de variation du courant égale à [1;120]mA. Pour correctement relever le courant, nous devons donc avoir en sortie une tension variant de 0 à 5V pour le courant allant de 0 à 120mA.
Nous nous basons sur le schéma ci-contre trouvé dans les datasheet du LTC6800 pour les calculs.
U=Rs*iL
Vout=G*U=G*Rs*iL => G=Vout(Rs*iL)
Or G=1+R2/R1
En prenant Vout/iL = 40mV/mA on a bien 4.8V pour 120mA. Soit G*Rs = 40mV/mA. On en déduit G et Rs.
Rs est limité par la puissance qu'il peut supporté. Si on prend Rs = 10 Ohm (G=4), on a donc une puissance de P=Rs*iL², Pmax=10*0.12²=0.144W. Avec une résistance supportant 0.25W (selon ses propriété), on peut donc prendre cette résistance de 10 Ohm.
G est défini par R2 et R1. On doit donc prendre R2/R1=3 donc par exemple R2 = 30 kOhm et R1 = 10kOhm. Comme 30kOhm n'est pas une valeur normalisée, on prend R2=27kOhm, notre gain sera plus petit.
Semaine 11
Nous avons eu quelques problèmes avec notre carte principale, concernant notamment le capteur de particules PM2.5. Après l'analyse de la Datasheet du PM_2.5, nous avions dans un premier temps prévu de relier les différentes entrées du capteur à un header relié aux pins correspondantes sur l'atmega. En réalité nous avons commis une erreur car le capteur n'est pas relié directement à l'atmega mais est connecté a un adaptateur. Or l'ordre des pins de l'adaptateur est différent de celui du capteur. De plus, la pin sleep (pour mettre en veille le capteur) est située au dessus de l'adaptateur et ne peut pas être connectée directement sur le header. Ainsi avec la nouvelle version du schématique nous avons réglé ce problème et on pourra ainsi connecter directement l'adaptateur sur le header et utiliser un câble mal/femelle pour relier la pin sleep de l'adaptateur à un autre header.
Ce ne sont pas des problèmes très graves, puisqu'il est toujours possible de faire fonctionner le capteur en utilisant un autre header et changer l'ordre des pins, mais c'est assez encombrant.
Comme nous avons reçu le LTC6800 et les résistances CMS 10 Ohm, nous avons pu imprimer et souder entièrement notre carte secondaire. Nous avons fait des tests pour vérifier que nos pins sont correctement connectées.
En fin de semaine, nous avons également imprimé la carte principale chez Mr. Flamen. Attendre celle venant de Chine et effectuer les changements sur cette dernière nous aurait fait perdre beaucoup trop de temps. Nous avons eu le temps de souder les composants CMS mais pas encore les composants traversants.
Semaine 12 (Vacances S1)
Nous avons pu avoir accès à Polytech durant quelques jours de cette semaine de vacances. Nous en avons donc profiter pour souder notre carte le plus possible.
Dans un premier temps, nous avons vérifié que nos composants CMS étaient bien soudés. Il y a eu besoin de quelques retouches au niveau du FTDI et de l'Atmega qui présentaient des courts-circuits. Nous avons ensuite souder les vias nécessaires aux premiers tests. En effet, avant de continuer à souder il a fallu être sûr que les micro contrôleurs étaient bien fonctionnels. Pour cela, nous avons relié l'Atmega à une Arduino via l'ISP présent sur notre carte, nous avons testé un programme pour faire clignoter une led (comme nous n'en avons pas sur la carte donc avons fait clignoter la led de l'Arduino). Cette étape étant validée, nous avons téléversé un bootloader pour pouvoir téléverser un programme cette fois depuis le FTDI. Avant ça, nous avons soudé le connecteur USB ainsi que les autres vias nécessaires. L'empreinte du connecteur USB variait légèrement au niveau des accroches, mais les broches correspondent bien donc nous avons écarté les accroches pour les souder directement à la masse. Puis nous avons essayé de téléverser un programme : les LED de sécurité du FTDI clignotent bien durant cette étape. Puis, toujours avec l'Arduino connecté avec l'ISP, nous avons téléversé le programme de Blinking led sur le FTDI qui lui-même l'a envoyé à l'Atmega qui une fois encore a bien fait clignoté la led de l'Arduino. Notre FTDI et notre Atmega sont donc bien fonctionnels et prêts à l'usage.
Dans un deuxième temps, nous avons donc pu souder le reste des composants, c'est-à-dire les headers pour les différents éléments (PM2.5, DHT22, Connecteur SD, Shield Bluetooth) ainsi que ceux utilisés pour mesurer la puissance consommée. Il y avait également le reste des vias, le Mosfet et le switch. Un fil connectant deux masses a été nécessaire. Cette partie ne fut pas sans encombres, car même si les composants étaient bien connectés à leur piste, il est arrivé qu'ils soient un tout petit peu connectés à la masse, perturbant le circuit.
Une fois tous les problèmes de connexion réglés, nous avons pu tester que les broches de l'Atmega envoient bien du 5V quand demandé.
Nous avons testé nos précédents programmes (du DHT22 et PM2.5) avec succès, en faisant bien attention de mettre en court-circuit les headers utilisés pour le circuit secondaire.
Nous obtenons les résultats suivants, la réception des données du capteur de température/humidité à gauche et celles du capteur de particules à droite.
Nous avons également établi un code de test pour vérifier que notre connecteur de carte SD fonctionne correctement. Dans le programme que l'on peut retrouver ci-contre, on crée un fichier "test.txt" dans lequel on écrit une petite ligne. On peut voir sur le moniteur série que la connexion se fait sans problème, puis on peut retrouver dans notre carte SD le fichier rempli correspondant.
Nous avons cependant rencontré quelques problèmes, déjà survenus auparavant : les header ne tiennent pas correctement et se dessoudent trop facilement de la carte. Cela provoque donc des mauvaises connexions. Une retouche est nécessaire.
Semaine 14
La semaine dernière, nous avons concaténé tous les codes afin d'écrire les valeurs obtenues sur la carte SD. Ayant des problèmes de connexions évoqués précédemment, les tests sur carte n'ont pu être réalisés que cette semaine (après retouches de soudures), d'où l'absence de rapport à la semaine 13.
Après quelques réflexions, nous avons donc décidé d'écrire les données sur deux différents fichiers : un pour le capteur DHT22 et un pour le capteur PM2.5. En effet, nous trouvons cela plus clair de cette manière.
De plus, nous les imprimons comme suit : une ligne correspond à un relevé de données, c'est à dire à une date précise (chronomètre lancé au démarrage) et au taux d'humidité puis à la température (pour le DHT22) correspondante. Ces valeurs sont séparées par des espaces pour que le fichier Excel puisse lui-même les disposer dans des cases différentes. Ainsi, les courbes sont très facilement réalisables.
De la même manière pour le PM2.5, chaque relevé correspond à une ligne comprenant le temps ainsi que les différentes valeurs de particules, le tout séparé par des espaces.
Un test de 20 minutes nous a permis d'obtenir 1250 valeurs et les courbes suivantes :
Nous n'avons pas affiché les courbes associées aux particules pm01, pm2.5 et pm10 puisqu'elles sont constantes autour de la valeur 65535.
On remarque que les données issues du capteur d'humidité/température DHT22 sont assez variables au cours du temps, même si elles ne fluctuent pas aussi rapidement que celles issues du PM2.5, elles mettent beaucoup de temps à se stabiliser. Pour revenir aux courbes du PM2.5, on peut au premier abord être surpris des grosses variations qu'elles présentent, cependant il n'en est rien puisque la valeur maximale qu'elles peuvent atteindre est de 65535 à expliquer . Leur fluctuation est donc minime.
Dans un second temps, nous avons voulu testé la mise en veille du capteur par la broche sleep ainsi que l'utilisation du mosfet (comme interrupteur de VCC).
Pour avoir des résultats un peu plus significatifs - ou plutôt visuels - que précédemment, nous avons déposé du talc sur le capteur, puis attendu une heure que cela devienne un environnement stable. On peut voir sur les graphe ci-contre que les valeurs sont plus élevées, notamment pour les courbes du a300nm, a500nm et a1um. Elles sont "stabilisées" autour de 50sec. De cette manière on peut mieux voir le temps que met le capteur à se mettre en route.
Nous avons donc ajouté dans le programme une partie permettant de mettre en veille le PM2.5 après 2min d'activité, cela pendant 30sec, puis le rallumer pendant 1min, le ré éteindre cette fois électriquement depuis le mosfet, encore une fois pendant 30sec puis le laisser fonctionner normalement à nouveau.
Les zones très constantes correspondent aux périodes ou le capteur est en veille. On voir que les données repartent de 0 à chaque redémarrage, quel qu'il soit. A première vue, en observant uniquement les données reçues, les deux mises en veille se valent. Nous allons quand même re effectuer des tests avec deux capteurs fonctionnant en même temps pour avoir des résultats plus précis.
Voici la partie de code que nous utilisons pour d'abord mettre le capteur en veille au bout de 120 secondes, le rallumer 30 secondes plus tard, attendre 60 secondes, faire de même avec l'utilisation du mosfet.
currentTime = millis();
if((currentTime > 120000 && is_pause==0) || (currentTime > 150000 && is_pause==1)) {
digitalWrite(set,!digitalRead(set));
is_pause++;
}
else if ((currentTime > 210000 && is_pause==2) || (currentTime > 240000 && is_pause==3)) {
digitalWrite(mosfet,!digitalRead(mosfet));
is_pause++;
}
Semaine 15
Relevés de courant et tension
Les premiers tests sur la carte étant effectués, il est enfin temps de réaliser l'étude énergétique de tous les éléments de la carte.
Initialement, nous avions pour objectif d'utiliser le montage high-side que nous avons réalisé afin mesurer la puissance consommée par nos différents éléments. Cependant, nous n'avons pas réussi à le faire fonctionner. Nous avons donc utilisé un multimètre avec lequel on a mesuré la tension et le courants consommés pour chaque capteur. Nous avons simplement relié les entrées du multimètre aux différents header prévu pour effectuer les relevés. Pour le courant, on connecte simplement le multimètre en série. Pour la tension, on connecte le COM à la masse du circuit (header prévu à cet effet), et le V au potentiel de l'élément en question. Il ne nous reste plus qu'à calculer la puissance avec P=U*I.
On obtient ainsi les résultats suivants:
- Pour le capteur DHT22 on a une consommation d'environ 1,2mA pour 5V soit P=6mW
- Pour le shield Bluetooth on a une consommation de 43/44mA (contre 50mA sur la datasheet) pour 5V soit P=215mW
- Pour le module de carte sd on a une consommation de 19mA pour 3,36V soit P=63mW
- Pour le capteur de particule, on différencie la consommation classique en marche qui vaut entre 30 et 50mA pour 5V soit P = 200mW ; et la consommation en mode veille qui vaut environ 9mA pour 5V soit P= 45mW. Pour le mode veille on observe un courant largement supérieur à celui indiqué par la datasheet (200uA). On pense que cela est du à l'adaptateur du capteur PM2.5 qui fausse le résultat notamment à cause des led qu'il utilise. Pour avoir une consommation précise, il faudrait souder des fils à l'entrée de l'adaptateur pour mesurer la puissance réelle dissipée.
Pour une étude énergétique plus poussée, nous avons observé les pics de courants du PM2.5 lorsqu'on l'allume électriquement (avec le MOSFET) et lorsque l'on sort du mode SLEEP. Etant impossible de mesurer ces pics avec un multimètre, nous avons donc opté pour l'oscilloscope. Nous n'avions cependant que des sondes de tension. Pour palier à ce problème, nous avons observé la chute de tension au borne d'une résistance de très petite valeur (10ohm) pour pouvoir ainsi en déduire le courant consommé. On règle ensuite l'oscilloscope de façon à observer le pic grâce au mode "single seq".
On a les relevés suivants, avec à gauche le pic de courant lors de la sortie du mode sleep vue à l'oscilloscope, et à droite celui après une mise en tension électrique (mosfet) :
Pour le mode sleep on a donc :
- en fonctionnement en veille consommant 45mW.
- un pic de courant au redémarrage allant jusqu'à 130mA, contre 9mA en mode sleep et 40mA en mode relevé de valeurs.
- la courbe peut être approchée par une droite (ou une exponentielle ?) afin d'en déduire la consommation énergétique.
Pour le capteur éteint par le mosfet on a :
- 0W de consommés.
- un pic de courant au redémarrage allant jusqu'à 500mA.
- la courbe peut-être approchée par une courbe de décharge d'un condensateur afin d'en déduire la consommation énergétique.
Etude de l'évolution des données
Nous avons ensuite voulu comparé les valeurs reçues par le PM2.5 avec un autre PM2.5 afin de voir au bout de combien de temps le capteur recommence à avoir des valeurs cohérentes et ainsi ne pas envisager une utilisation du mode sleep par exemple, avec un intervalle entre les mises en veille trop court.
Dans un premier temps, nous avons eu le PMS7003, qui malheureusement n'a pas affiché de valeurs cohérentes avec notre capteur : même avec un dépôt de poussière, il ne détectait pas de changement d'environnement. Nous avons alors eu la possibilité de refaire ces tests avec un PM2.5 identique à notre capteur initial. Les valeurs sont bien plus cohérentes même si on observe une différence d'échelle entre les deux. Nous allons notamment comparer les valeurs reçues (différence prise en compte) depuis les valeurs de a300nm, puisque c'est la courbe la plus exploitable.
De la même manière que précédemment, nous avons donc déposé de la poussière sur les capteurs aux alentours de 10 secondes. On remarque que les deux capteurs réagissent. Ensuite, au bout de 30secondes et pendant 10secondes le capteur est mis en mode sleep. Nous attendons alors 2minutes avant de faire de même en l'éteignant électriquement.
On peut noter qu'en fonctionnement on a une différence d'environ 500. Cela ne pose pas de problème puisque l'on peut bien observer le temps de remise en route du capteur dans les deux cas. Nous allons maintenant uniquement prendre en compte les valeurs à partir de 30 secondes afin de retirer la partie où la poussière est ajoutée et ainsi pouvoir correctement analyser les valeurs.
On s’intéresse maintenant aux temps de réponse pour les deux modes (sleep/allumé et éteint/allumé). Ce temps de réponse correspond au temps nécessaire du capteur à récupérer des données valides. Ainsi avec ce temps, on sera capable de calculer l'énergie perdue lors de cette phase. On voulait initialement utiliser le second capteur pour référence afin de déterminer le plus précisément possible l'instant où le capteur récupérait des données valides. Malheureusement, même si on observait une différence d'environ 500 entre les deux capteur (pour le nombre de particules a300), cet écart n'est en réalité pas assez stable pour pouvoir trouver précisément l'instant recherché.
Avec des interprétations, on est tout de même capable de déterminer approximativement le temps de montée pour les deux modes. On observe ci dessous le temps de réponse pour les deux modes (on observe la réponse du capteur pendant 40 secondes).
On remarque que le temps de réponse du capteur est sensiblement plus rapide quand on passe du mode sleep au mode normal (7s plus rapide). Ainsi on privilégiera certainement cette méthode si on souhaite effectuer des relevés à une fréquence élevée. On notera tout de même qu'il est absurde de mettre en veille/d'éteindre le capteur si on effectue des relevés toutes les 20s ou moins.
Nous avons dans un premier temps calculé l'énergie consommée dans le capteur, dans les trois cas (normal, utilisation du mode sleep, utilisation du mosfet).
Nous avons considéré une période T entre deux relevés de valeurs. Ces valeurs sont considérées comme cohérentes et c'est pour cela que nous ré utilisons les données déduites précédemment : le temps entre la fin du mode sleep (respectivement le moment où l'on rallume électriquement) et le relevé doit correspondre à 13s (respectivement 20s).
C'est pour cela que notre calcul d'énergie se décompose en trois parties. Comme il faut laisser trs=13sec (trm=20sec) avant d'effectuer le relevé, on calcule l'énergie véhiculée pendant le mode sleep (le capteur éteint par le mosfet) entre 0s et T-trs (T-Trm). Puis pendant le pic de courant approximé par l'aire d'un triangle rectangle, avec pic_sleep le point de courant le plus haut, tpic_sleep le temps avant de retrouver un courant équivalent au courant normal (pic_mosfet et tpic_mosfet). Enfin, le reste de la période est un fonctionnement normal (jusqu'à temps que les valeurs soient cohérentes) c'est-à-dire la puissance normale pendant trs-tpic_sleep (trm-tpic_mosfet).
On remarque donc que l'énergie consommée lors de l'utilisation du mosfet ne dépend pas de la période, tant que celle-ci est supérieure à trm=20s. Ici on a :
- tension = 5V
- courant_normal = 0,04A
- trm = 20s ; pic_mosfet = 0,5A ; tpic_mosfet = 1,6ms ; soit Em = 4,00148J
- trs = 13s ; pic_sleep = 0,13A ; tpic_sleep = 0,8ms
On cherche alors à partir de quelle valeur de T l'utilisation du mode sleep est recommandée. On prend un premier cas avec courant_sleep = 0,009A et un autre avec courant_sleep = 0,0002A (datasheet).
D'après les calculs ci-contre, on obtient donc T < 44s pour le premier cas (valeur expérimentale de courant_sleep) et T < 1414 (valeur théorique).
Nous faisons ensuite de même en comparant l'utilisation du mode sleep et aucune mise en veille (mode normal). On a alors le mode sleep privilégié pour T > 13,0006s pour le courant_sleep expérimental et T > 13,0005s pour la valeur théorique.
La variable courant_sleep est donc peu importance pour déterminer quelle utilisation entre le mode sleep et le mode normal est à privilégié, dans tous les cas il faut considérer qu'en dessous de 13,1 secondes il est préférable de laisser le capteur toujours allumé. On peut noter que c'est complètement en adéquation (et sûrement lié) avec notre valeur de trs (13secondes avant d'obtenir des relevés cohérents). En revanche, lors de la comparaison entre l'utilisation du mode veille et le mosfet, la valeur courant_sleep a un impact très important : avec notre valeur expérimentale, le mosfet est largement préféré puisque le mode sleep ne peut être utilisé pour T entre 13s et 44s soit une très faible fenêtre de mesures. En revanche, avec la valeur théorique il faut une période d'une vingtaine de minutes avant de pouvoir utiliser judicieusement le mosfet.
On peut donc maintenant, pour une période entre deux mesures données, déterminer quelle est la meilleure configuration.
Désormais, nous allons essayer de prédire l'autonomie d'une batterie selon le mode utilisé. Pour cela, les calculs sont légèrement différents. En effet, une batterie se caractérise par ses Ampères-heure et non ses Joules. Nous avons donc calculé la valeur moyenne du courant traversant le PM2.5 (calculs ci-contre). Une fois cette valeur trouvée, on l'ajoute au reste des valeurs de courant des autres composants. On s'assure également d'ajouter la consommation de l'atmega 328p qui s'élève à environ 15mA en fonctionnement normal. On divise alors la valeur en A-h de la batterie par cette valeur de courant moyen total, ce qui nous donne une valeur en heures de l'autonomie de la batterie.
On a aussi réalisé un petit programme c permettant de calculer l'autonomie du système complet en fonction de la capacité de la batterie donnée en paramètre et de la fréquence de relevé de valeur sur le pm2.5. On peut également changer une variable globale pour passer de la valeur de consommation en veille du pm2.5 expérimentale à celle de la datasheet
On peut encore une fois voir que l’utilisation continue du capteur PM2.5 n’est conseillée que jusqu’à une dizaine de secondes. L’utilisation du mode sleep reste privilégiée jusqu’à une quarantaine de secondes en utilisant la valeur expérimentale de son courant en mode veille contre 1500 pour la valeur théorique où l’utilisation du mosfet est alors une meilleure solution. Cependant, on remarque que si l’on considère la valeur théorique de courant_sleep, l’autonomie entre cette configuration et l’arrêt électrique est très proche.
Si notre capteur est utilisé pour effectuer des relevés toutes les heures ou encore quotidiens, alors l’arrêt électrique du capteur de particules est à privilégier puisque jusqu’à 20h d’autonomie peuvent être gagnée sur une batterie de capacité 5Ah. Dans ce cas, le module de communication devrait être à revoir, puisqu’un module bluetooth y perdrait son sens. En enlevant ce module on peut gagner plus de 60heures d’autonomie. Dans la même optique, le module SD pourrait être programmé différemment afin de ne pas perdre les fichiers quand il est éteint, et ainsi toute la carte pourrait être mise en veille avec l’Atmega.
Documents Rendus
Rapport de projet: Fichier:P63 lorthios obled.pdf
