Wiki de Projets IMA - Contributions de l’utilisateur [fr]

P32 Récupération d'énergie pour balise BLE

2016-02-22T19:50:10Z

Qsultana : /* Rapport de Mi-projet */

== Objectif ==

Mon projet consiste à réaliser un système électronique autonome, composé de différents capteurs et capable de recueillir et de transmettre les données mémorisées vers un système centralisé.

== Etude préalable ==

L’énergie est le point de difficulté dans la réalisation de ce projet. Chaque élément devra être choisi non seulement pour ses performances mais également pour sa faible consommation.

== Organisation générale ==

Le système est organisé autour d’une source d’énergie, d’un contrôleur, de capteurs, de mémoire et d’un protocole de communication.

On cherche à minimiser l'énergie consommée par l'ensemble du système.

[[Fichier:P32Ensemble.PNG|250px|thumb|left|'''Architecture''']]

=== Chaine de l’énergie ===

L’énergie pour ce module autonome est constituée de quatre phases importantes :

[[Fichier:P32Energie.PNG]]

==== La récupération de l'énergie dans l'environnement ====

Il existe de nombreux moyens pour récupérer de l'énergie dans l'environnement. L'objectif est de trouver les sources les plus adaptées à l'environnement de l'application recherchée.

On peut citer:

* La récupération de l'énergie par différence de température

* Les panneaux photovoltaïques

* La récupération de l'énergie des ondes radio

* La Piézoélectricité

Dans ce projet nous utiliserons la piézoélectricité, le module de récupération ayant déjà fait partie d'une étude de IRCICA précédent le projet.

==== Le stockage de l’énergie ====

Le choix du système de stockage de l'énergie constitue une partie importante de la réalisation du système.
La problématique de cette partie sera de déterminer quel type de stockage nous utiliserons : batterie, super-capacité ou un hybride et de les dimensionner.
Il faudra tenir compte des problèmes de décharge partielle influent sur la durée de vie du stockage.

==== Le management/mise en forme de l’énergie ====

L'objectif de cette partie est d'étudier la nécessité de la mise en place d'une régulation tout en préservant des contraintes de consommation très faibles.

==== L'utilisation de l'énergie mise en forme ====

On cherche à minimiser l'énergie consommée par l'ensemble du système.

=== Contrôleur ===

Le microprocesseur : il existe différents types de microprocesseurs. L'objectif est de choisir un support capable de consommer un minimum d'énergie tout en conservant une taille minimale. Nous avons déjà utilisé dans d'autres projets des micro-contrôleurs de type Arduino et Raspberry pie. Ceux-ci ont pour avantage d’être prêts à l'emploi et faciles de prise en main. On peut s’orienter également vers un contrôleur ultra low power comme le STM32L4.

{| class="wikitable centre" width="80%"
|+
|-
! scope=col |
! scope=col | Consommation
! scope=col | Facilité de développement
! scope=col | Miniaturisation
|-
| width="33%" |
<center>Arduino</center>
| width="34%" |
<center>faible à très faible</center>
| width="33%" |
<center>bonne</center>
| width="33%" |
<center>faible</center>
|-
| width="33%" |
<center>Raspberry pi</center>
| width="34%" |
<center>importante</center>
| width="34%" |
<center>très bonne</center>
| width="34%" |
<center>très faible</center>
|-
| width="33%" |
<center>Ultra low power</center>
| width="34%" |
<center>très, très faible</center>
| width="33%" |
<center>difficile</center>
| width="33%" |
<center>forte</center>
|}

=== Capteurs ===

On peut imaginer différents types de capteurs :

* Accéléromètre

* Gyroscope

* Pression atmosphérique et altitude

* Température

* GPS

=== Mémoire ===

Le système doit être autonome et donc conserver un minimum de mesures pour les cas où la connexion est impossible. La mémoire doit être dimensionnée en fonction du nombre de capteurs, l’intervalle d’acquisition et le temps maximum avant connexion au système centralisé.

=== Protocole de communication ===

Un protocole de communication : dans un premier temps, nous nous concentrons sur le protocole BLE (Bluetooth Low Energie). Ce protocole étant standardisé, il nous permettra de recueillir de la documentation et réaliser des tests de consommation rapides.

== Planning prévisionnel ==

[[Fichier:P32Gant.PNG]]

==Suivi de l'avancement du Projet==
===Semaine 1 (28/09/2015)===

* Rencontre avec Monsieur Boe et Monsieur Giraud

* Présentation du projet

* Recherche documentaire

* Etablissement du cahier des charges

===Semaine 2 (05/10/2015)===

Recherche documentaire sur la consommation estimée des différents éléments.

{| class="wikitable centre" width="80%"
|+
|-
! scope=col | '''Contrôleur'''
! scope=col | Consommation Active
! scope=col | Consommation Inactive
! scope=col | Prix
|-
| width="33%" |
<center>Arduino Pro Mini 328 </center>
| width="34%" |
<center> 7mA (1 capteur)</center>
| width="33%" |
<center>4.5µA</center>
| width="33%" |
<center>Disponible</center>
|-
| width="33%" |
<center>STM32L4 Series (STM32L476JE)</center>
| width="34%" |
<center> 100 μA/MHz</center>
| width="33%" |
<center>120 nA</center>
| width="33%" |
<center>$5</center>
|-
| width="33%" |
<center>Raspberry</center>
| width="34%" |
<center> 200mA </center>
| width="33%" |
<center>200mA</center>
| width="33%" |
<center>Disponible</center>
|}

{| class="wikitable centre" width="80%"
|+
|-
! scope=col | '''Module BLE'''
! scope=col | Consommation
! scope=col | Options d'alimentation
! scope=col | Prix
|-
| width="33%" |
<center>BLE Mini</center>
| width="34%" |
<center> 15 mA </center>
| width="33%" |
<center>3.4V à 11V VIN / 5V USB / Coin Cell Battery (2025 or 2032) / 3.7V Li-ion Battery</center>
| width="33%" |
<center>$17</center>
|}

* <s> Le système Mini Arduino/ BLE Mini me semble être un bon compromis entre facilité d’intégration, consommation d'énergie et miniaturisation du système.</s> (Choix à discuter à la réunion du Merdredi 07/10)
* Choix du module RFduino

{| class="wikitable centre" width="80%"
|+
|-
! scope=col | '''Capteurs'''
! scope=col | Modèle
! scope=col | Alimentation min/max
! scope=col | Prix
|-
| width="33%" |
<center>Température</center>
| width="34%" |
<center> TMP36GT9Z </center>
| width="33%" |
<center>2.7V/5.5V</center>
| width="33%" |
<center>1,46 €</center>
|-
| width="33%" |
<center>Accéléromètre</center>
| width="34%" |
<center> ADXL345BCCZ </center>
| width="33%" |
<center>2V/3.6V</center>
| width="33%" |
<center>5,54 €</center>
|-
| width="33%" |
<center>Gyroscope+Accéléromètre</center>
| width="34%" |
<center> MPU-6050</center>
| width="33%" |
<center>2.5V/3.6V</center>
| width="33%" |
<center>15,73 €</center>
|-
| width="33%" |
<center>Pression atmosphérique / Altitude</center>
| width="34%" |
<center> MPL3115A2 </center>
| width="33%" |
<center>1.95V/3.6V</center>
| width="33%" |
<center>2,65 €</center>
|}

* Pour minimiser les pertes on cherche a travailler avec une tension d'alimentation la plus faible possible. Je propose de travailler avec une tension d'alimentation de 3,3V (Validé à discuter à la réunion du Merdredi 07/10)

* Le système de récupération d'énergie fonctionnant sur la base d'un mouvement, j'ai choisi l'ensemble des capteur ci dessus qui me semble être adapté à l'intégration dans un système en mouvement. (Validé à discuter à la réunion du Merdredi 07/10)

* Récupération des modules RFduino, prise en main

===Semaine 3 (12/10/2015)===

* Installation des librairies

* Visualisation d'exemples

* Tests d'implantation du code source du projet P14: Aimant intelligent de la session IMA4: 2014/2015

* Optimisation du code pour la réduction de la consommation d'énergie

* Recherches sur d'autres composants dans l'optique d'une consommation toujours plus faible

{| class="wikitable centre" width="80%"
|+
|-
! scope=col | '''Capteurs'''
! scope=col | Modèle
! scope=col | Alimentation min/max
! scope=col | Prix
! scope=col | Consommation (typ/max)
|-
| width="33%" |
<center>Température</center>
| width="34%" |
<center> STLM20W87F </center>
| width="33%" |
<center>2.4V/5.5V</center>
| width="33%" |
<center> 0,775 € </center>
| width="33%" |
<center> 4.8 μA/8.0 μA </center>
|}

'''Calcul théorique de la consommation énergétique du module BLE + RFD22301'''

Mode "endormi" : ARM CPU Running Current + Output standard drive current = 4 + 0.5 = 4.5mA

Mode "acquisition": ARM CPU Running Current + Output high drive current = 5 + 4 = 9mA

Mode "transmission" : ARM CPU Running Current + Transmit Current + Output standard drive current = 4 + 0.5 + 12 = 16.5mA

http://www.rfduino.com/wp-content/uploads/2014/03/RFD22301.Data_.Sheet_.11.24.13_11.38PM.pdf

'''Code possible du mode "endormi"'''

pinMode(5, INPUT);
RFduino_pinWake(5, HIGH);

RFduino_ULPDelay(INFINITE);
if (RFduino_pinWoke(5))
{
state = ! state;
RFduinoGZLL.sendToHost(state);
}

http://forum.rfduino.com/index.php?topic=385.0

===Semaine 4 (19/10/2015)===

* Réunion du 21/10

* Réalisation de tests

* Ajustement du nombre de capteurs : dans un premier temps on utilisera le capteur de température puis l'accéléromètre

* Discussion sur le bac de test et méthodes de test : résistance de visualisation, chronométrage du temps de transmission, vitesse du processeur

* Réalisation des premiers relevés

===Semaine 5 (26/10/2015)===

* Recherche bibliographique sur les modes d'endormissement du module RFduino

* Essais de codes utilisant un mode d'endormissement plus profond

* Réalisation de graphique de l'énergie utilisée par le module lors de la transmission d'un message par le module BLE.

* Recherches sur des méthodes de programmation pour la diminution de la vitesse processeur

[[Fichier:P32Montage.jpg|250px|thumb|left|'''Montage de test''']]
[[Fichier:P32resultats.jpg|250px|thumb|center|'''Visualisation du courant consommé lors d'envoi toutes les 10ms''']]

* On visualise à l'oscilloscope des pic d'envoi et des pic d'avertissement de la balise BLE, on peut ainsi déduire la puissance nécessaire de chaque action

===Semaine 6 (02/11/2015)===

* Test de diminution de la vitesse processeur

* Réalisation de graphique démontrant l'impact de la réduction de la vitesse processeur sur l'énergie consommée et déduction d'une vitesse optimale pour notre application

* Réunion du 4/11

Définition d'objectifs : Création d'un fichier excel permettant de caractériser les coûts en énergies de chaque étapes de fonctionnement du système.

* Création d'un environnement de test "normé" ( Pour éviter les variations de mesures on réalise un banc et on applique les mêmes conditions de test pour chaque essai)

* Recherche bibliographique sur la norme BLE : recherche du temps maximum entre deux "avertissements" de la balise BLE

===Semaine 7 (09/11/2015)===
* Explication du principe de communication BLE pour l'exploitation des résultats

[[Fichier:Freq.PNG]]

Nous nous intéressons dans notre projet à "l'observateur". Cet objet peut avoir trois états : stand-by, advertising et en communication.

[[Fichier:Brod2.png]]

Dans le mode "Advertising" le système peut :

- Avertir le système récepteur de la proximité d'un capteur

- Avertir de la présence à un appareil souhaitant ce connecter

- Ce reconnecter de façon asynchrone

===Semaine 8 (16/11/2015)===

Analyse en détail d'une trame BLE

[[Fichier:Com.PNG]]

On constate que pendant la durée de la trame il y a un échange entre les deux objets appairé. On s’intéresse ici uniquement aux actions "Slave Tx". Le but étant d'identifier la durée et le courant consommé par ces actions pour obtenir des valeurs en joules.

[[Fichier:SchemaCom.PNG]]

On constate donc deux phases :

- Advertising event

- Connexion event

Nous allons essayer de retrouver et quantifié l'énergie consommé dans ces deux phases.

===Semaine 9 (23/11/2015)===

Lors de cette semaine nous avons effectué des tests en respectant une procédure de test précise. En effet les valeurs des courants que nous relevons sont très petites aussi chaque variation du montage est susceptible de perturber les valeurs.

[[Fichier:P32Conne.jpg|250px|thumb|left|'''Phase connexion''']]

[[Fichier:Avertissement.jpg|250px|thumb|center|'''Phase Advertising''']]

===Semaine 10 (30/11/2015)===

- On cherche a diminuer légèrement la consommation par des modifications logiciel :

Réduction de la puissance de la radio BLE : Diminution de la portée

Augmentation de la fréquence d'advertising : tant que la fréquence d'advetising est inférieure a cette de relevé des capteurs on s'assure que la donnée envoyée est toujours mise à jour.

[[Fichier:Pwl20-envoi.jpg|250px|thumb|left|'''Avec modification logiciel''']]

[[Fichier:Sans-pwlvl.jpg|250px|thumb|center|'''Sans modification logiciel''']]

- On concentre nos résultats dans un tableau récapitulatif en vue du dimensionnement de la batterie du système

[[Fichier:P32tbresul.PNG]]

===Semaine 11 (07/12/2015)===

Tests d'intégration de plusieurs capteur et observations des modification de la consommation des ADC et de la durée/consommation de la transmission.

Réunion de vérification des tests.

Mise en évidence de la dualité consommation d'énergie - Temps de réponse du système

En effet chaque "Advertisement" consomme une quantité d'énergie nous pouvons gérer l'espacement entre ceux-ci mais plus ce temps serra élevé plus il faudra de temps pour ce connecter à ce périphérique.

* Rédaction d'un rapport de test

* Rédaction du rapport de pré soutenance

===Semaine 12 (14/12/2015)===

* Recherches de solutions pour l'amélioration du modèle
* Recherches Matlab pour effectuer une analyse statistique d’avènements aléatoires sur la liaison

===Semaine 13 (04/01/2016)===

*Amélioration du modèle

L’amélioration du modèle est réalisée en tenant compte des facteurs influant sur la qualité de la transmission.

* Utilisation d'un picoscope : appareil permettant l’acquisition sur ordinateur de plusieurs formes d'ondes.
Ainsi grâce à un pico scope utilisé à l’IRCICA j’ai pu relever de nombreux échantillons nécessaires à une étude statistique des surcoûts en énergie.

[[Fichier:Montagemulti.jpg|250px|thumb|left|'''Montage multi récepteur''']]

===Semaine 14 (11/01/2016)===

* Compilation des résultats

* Exploitation Matlab

[[Fichier:Emistbrecap.PNG]]

===Semaine 15 (18/01/2016)===

Principe de fonctionnement du récupérateur d’énergie

Le récupérateur d’énergie fonctionne grâce à un patch piezo. Ce patch est capable de produire un courant à partir de la vélocité d’une impulsion suivant la formule :

[[Fichier:Equapiezo.PNG]]

[[Fichier:Modelepizo.PNG|250px|thumb|left|'''Modèle simplifié du patch piezo''']]

Pour récupérer de l’énergie il est couplé au système suivant :

[[Fichier:montagepiezo.PNG]]

La puissance du système est définie par :

P=V*im

L’énergie s’exprime alors :

[[Fichier:Equaenergie.PNG]]

L’énergie produite par le système est donc dépendante de la tension d’alimentation V de la constante électromécanique N et du choc produit sur le patch piezo.
Une impulsion sur le capteur piezo est de la forme :

La dérivée par rapport au temps de cette impulsion est donc de la forme :

Il est donc important de « fenêtrer » la tension pour ne récupérer que la partie positive.
Ce fenêtrage ainsi que la fréquence de commutation du hacheur sont assurés par un microcontrôleur.

Dans la suite de notre étude nous ne tiendrons pas compte de la consommation de celui-ci.

===Semaine 16 (25/01/2016)===

* Réflexions sur le prototypage

* Présentation du récupérateur

* Mise en place du banc de test

* Premiers relevés

[[Fichier:Montagepiezo.jpg|250px|thumb|left|'''Montage piezo''']]
[[Fichier:Patchpiezo.jpg|250px|thumb|center|'''Patch piezo''']]

===Semaine 17 (01/02/2016)===

Test de la quantité d’énergie récupérée par un patch piezo

Méthodologie :

Channel rouge : Tension aux bornes du patch piezo. Ici on observe une fenêtre de tension de 4,5ms imposée par le microcontrôleur.

Channel vert : Tension aux bornes de la capacité C1 de 220nF
[[Fichier:Diffpot.png|250px|thumb|center|'''Tension patch piezo / Tension C1''']]

On constate qu’un choc sur le patch piezo produit une énergie suivant la formule, E = V * N * Δw
N étant une constante électromécanique, on va faire varier V pour évaluer le gain en énergie. Cependant Δw est généré par un choc d’un stylo sur le patch il n’est donc pas uniforme.
Nous utilisons donc une méthode statistique qui consiste à retirer deux extrémums et faire la moyenne de 10 mesures.

Nous obtenons la courbe suivante :

On constate que la courbe n’est pas linéaire comme l’aurait laissé supposer la formule. En effet jusqu’à 30V elle est linéaire croissante suivant l’équation :

Puis après 50V elle devient quadratique décroissante suivant la formule :

En effet la formule E = V * N * Δw néglige les pertes. Celles-ci deviennent plus importantes à chaque augmentation de la tension d’alimentation.

On obtient donc un point de fonctionnement optimal à 50V pour notre système. Ce qui impose que notre système soit équipé d’une source de tension en conséquence.

===Semaine 18 (08/02/2016)===

*Réalisation de nombreux tests pour confirmation de la caractéristique

[[Fichier:P32Courbe.png]]

*Recherches de solution pour la réalisation d'un convertisseur buck pour passer de la tension récupérée ( ~ 50V ) au récupérateur d'énergie puis au module BLE ( 3.3 V )

*Solution 1 : http://www.ti.com/lit/ds/symlink/tps54060.pdf

*Solution 2: http://fr.farnell.com/stmicroelectronics/l78l33acz/regulateur-3-3v/dp/1467768

===Semaine 19 (15/02/2016)===

*Rédaction du rapport

===Semaine 20 (22/02/2016)===

*rédaction du rapport

== Annexes ==

Consommation du STM32L4 Series : http://www.st.com/web/en/catalog/mmc/FM141/SC1169/SS1580?sc=stm32l4

Réduction de la consommation de l'Arduino : http://www.home-automation-community.com/arduino-low-power-how-to-run-atmega328p-for-a-year-on-coin-cell-battery/

Consommation Raspberry : https://www.raspberrypi.org/help/faqs/

Module BLE : http://redbearlab.com/blemini/

Accéléromètre : http://fr.farnell.com/analog-devices/adxl345bccz/accelerometre-3-axes-14lga/dp/1853935

Capteur température : http://fr.farnell.com/analog-devices/tmp36gt9z/capteur-temp-to-92-3/dp/1438760?ost=TMP36GT9Z
ou http://fr.farnell.com/stmicroelectronics/stlm20w87f/capteur-de-temperature-analog/dp/1391131

Accéléromètre + Gyroscope : http://fr.farnell.com/invensense/mpu-6050/gyroscope-accelero-6-axes-i2c/dp/1864742

Altimètre : http://fr.farnell.com/freescale-semiconductor/mpl3115a2/pressure-sensor-20-110kpa-8lga/dp/2009084?ost=MPL3115A2&categoryId=700000004367

Explications norme BLE : chapters.comsoc.org/vancouver/BTLER3.pdf

http://www.argenox.com/bluetooth-low-energy-ble-v4-0-development/library/a-ble-advertising-primer/

----

Fichiers MATLAB

[[Fichier:Recuperation.zip]]

[[Fichier:Recuperation3.zip]]

== Rapport de Mi-projet ==

[[Fichier:CR_Miprojet_Sultana.pdf‎ ]]

== Rapport projet ==

[[Fichier:Rapport_P32_Sultana.pdf]]

Projets IMA5 2015/2016

2016-02-22T19:49:23Z

Qsultana : /* Répartition des binômes */

Merci de référencer vos pages de projets ici. Merci aussi d'uniformiser vos formats que ce soit en regardant la présentation des projets déjà créés ou en allant modifier le format des précédents si votre façon de faire vous semble la meilleure. Dans tous les cas un minimum de communication entre les binômes est conseillée.

Toutes les sources doivent être déposées sur notre archive GIT. Le service est disponible à l'URL [https://archives.plil.fr archives.plil.fr]. Connectez-vous avec vos identifiants Polytech'Lille. Sauf indication contraire de vos encadrants, rendez le projet public et mettez le lien sur votre Wiki. Vous pouvez trouver de la documentation sur ce système d'archives sur ce [https://git-scm.com/book/fr/v1 site].

== Répartition des binômes ==

<table border="1">
<tr>
<th>Projet</th>
<th>Elèves</th>
<th>Encadrant Ecole</th>
<th>Rapport décembre</th>
<th>Rapports finaux</th>
<th>Vidéo</th>
</tr>
<tr>
<td>[[P1 Convertisseur DC/DC pour réseau MTDC]]</td>
<td> Mehmet Ilter </td>
<td> Philippe DELARUE </td>
<td> </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P2 Data Logger]]</td>
<td> Hidéo VINOT</td>
<td> Alexandre Boé / Thomas Vantroys </td>
<td> 15/12/2015 12;00</td>
<td> </td>
<td> mercredi 24 février à 10h avec L. Engels</td>
</tr>
<tr>
<td>[[P4 Jukebox multi-pièces]]</td>
<td> Alexandre Jouy / Julien hérin </td>
<td> Rodolphe Astori / Xavier Redon / Alexandre Boé / Thomas Vantroys </td>
<td> [[Fichier:Pre_soutenance_PFE_Jouy_herin.pdf]] </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P9 Système d'hébergement domestique]]</td>
<td> Romain Libaert / Timothée Teneur </td>
<td> Xavier Redon / Alexandre Boé / Thomas Vantroys </td>
<td> 15/12/2015, 10:21, [[Fichier:P9_LIBAERT_TENEUR_DEC15.pdf]]</td>
<td> </td>
<td> Tournée le 22/02 par M. Engels</td>
</tr>
<tr>
<td>[[P10 LILLIAD: Connected Learning Center | P10 LILLIAD: learning center connecté]]</td>
<td> Mageshwaran Sekar </td>
<td> Alexandre Boé / Thomas Vantroys </td>
<td> 15/12/2015,07:48, [[Fichier:P10_FYP_December_Report_M_SEKAR.pdf]]</td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P11 Spectateur augmenté]]</td>
<td> Teresa Tumbragel </td>
<td> Alexandre Boé / Thomas Vantroys </td>
<td> </td>
<td> [[Fichier:Teresa Tumbragel-Rapport Spectateur Augmente.pdf]] </td>
<td> NA </td>
</tr>
<tr>
<td>[[P12 Capteurs enfouis pour vieillissement du béton]]</td>
<td> JULITA Alex </td>
<td> Alexandre Boé / Thomas Vantroys </td>
<td> </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P14 Localisation dans le corps humain]]</td>
<td> Matthieu Marcadet </td>
<td> Alexandre Boé / Thomas Vantroys </td>
<td> 15/12/2015, 10:52, [[Fichier:Rapport_intermediaire_PFE_Marcadet.pdf]]</td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P18 Meuble intelligent]]</td>
<td> Kevin Colautti / Benjamin Lefort </td>
<td> Rémy Bernard / Alexandre Boé / Xavier Redon / Thomas Vantroys </td>
<td> 14/12/2015, 14:44, [[Fichier:P18_pre_soutenance.pdf]]</td>
<td> </td>
<td> RDV L. Engels le 22/02 </td>
</tr>
<tr>
<td>[[Automatic Soldering System Project|P20 Placeur de composants sur PCB]]</td>
<td> Jean Wasilewski & Pierre Letousey </td>
<td> Xavier Redon / Thomas Vantroys / Alexandre Boé </td>
<td> [[Fichier:P20_ASSP.pdf]]</td>
<td> </td>
<td> Rendez-vous pris avec M. Engels le vendredi 25 Février à 10h </td>
</tr>
<tr>
<td>[[P24 Nuage pour sites Web]]</td>
<td> Jeremie Denechaud / Thibaut Scholaert </td>
<td> Xavier Redon / Thomas Vantroys </td>
<td> 15/12/2015, 12:02, [[Fichier:P24_Denechaud_Scholaert.pdf| Rapport intermédiaire de projet]]</td>
<td> </td>
<td> Fait Maison</td>
</tr>
<tr>
<td>[[P25 Architecture ROS pour des véhicules autonomes intelligents]]</td>
<td> Jean-Michel Tournier / Cyril Smagghe </td>
<td> Vincent Coelen et Rochdi Merzouki </td>
<td> 15/12/2015,09:04, [[Fichier:P25-2015_Smagghe_Tournier_decembre.pdf]]</td>
<td> </td>
<td>RDV mercredi 24 15h </td>
</tr>
<tr>
<td>[[P26 Robot de forgeage et d’usinage]]</td>
<td> Bertrand Yvernault / Louis Thebault </td>
<td> Rochdi Merzouki </td>
<td> 14/12/2015, 17:51</td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P27 Robot de fraiseuse]]</td>
<td> Flavien Royer / Maxime Morisse </td>
<td> Rochdi Merzouki </td>
<td> 14/12/2015, 19:06, [[Fichier:Rapport_Royer_Morisse.pdf]]</td>
<td> </td>
<td> </td>
</tr>

<tr>
<td>[[P30 Thermostat connecté et intelligent]]</td>
<td> TISSOT Elise / TIRABY Céline </td>
<td> Guillaume Renault / Alexandre Boé / Xavier Redon </td>
<td>15/12/2015, 00:35, [[Fichier:Rapport_PFE_TISSOT_TIRABY.pdf‎ ]] </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P32 Récupération d'énergie pour balise BLE]]</td>
<td> Quentin Sultana </td>
<td> Frédéric Giraud / Alexandre Boé / Thomas Vantroys </td>
<td> 13/12/2015, 19:31, [[Fichier:CR Miprojet_Sultana.pdf]]</td>
<td> [[Fichier:Rapport_P32_Sultana.pdf]]</td>
<td> RDV L. Engels le 24/02 </td>
</tr>
<tr>
<td>[[P33 Réalisations en faveur de l'accessibilité de jeux vidéos]]</td>
<td> Jérôme Bailet / Mehdi Zeggaï </td>
<td> GAPAS / Laurent Grisoni / Thomas Vantroys </td>
<td> 14/12/2015, 10:54, [[Fichier:PFE_IMA5_Rapport_intermediaire_Bailet_Zeggai.pdf]]</td>
<td> </td>
<td> RDV L. Engels le 25/02 </td>
</tr>
<tr>
<td>[[P35 Robot de test pour le sport de Golf]]</td>
<td> Deborah Saunders </td>
<td> Rochdi Merzouki </td>
<td> 15/12/2015, 12:07</td>
<td> </td>
<td> </td>
</tr>

<tr>
<td>[[P34 Optimisation de trajectoire pour un robot de curiethérapie]]</td>
<td> Sandra HAGE CHEHADE / Thomas DANEL </td>
<td> Vincent COELEN / Rochdi MERZOUKI </td>
<td> 15/12/2015, 12:02</td>
<td> </td>
<td> </td>
</tr>

<tr>
<td>[[P40 Maquette mécatronique durcie d'ascenseur 5 étages]]</td>
<td> Louis CHAUCHARD / Romain IMBERT </td>
<td> Blaise CONRARD </td>
<td> 14/12/2015, 19:21</td>
<td> </td>
<td> RDV L. Engels le 23/02 </td>
</tr>
<tr>
<td>[[P13 Plateforme expérimentation IOT]]</td>
<td> ROCHE François </td>
<td> Alexandre Boé / Thomas Vantroys </td>
<td> 14/12/2015, 19:37, [[Fichier:PFE_P13_Plateforme_expérimentation_IOT.pdf]] </td>
<td> </td>
<td> Tournée le 22/02 par M. Engels </td>
</tr>
<tr>
<td>[[Implantation d'un filtre FIR-FX-LMS sur FPGA pour l'annulation de Bruit Acoustique]]</td>
<td> Bown Alexander / Piat Valentin </td>
<td> Alexandre Boé / Thomas Vantroys </td>
<td> NA </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[Pilulier automatique]]</td>
<td> Manouk Simon / Corentin Duplouy </td>
<td> Alexandre Boé / Thomas Vantroys </td>
<td> NA </td>
<td> </td>
<td> RDV L. Engels le 23/02 </td>
</tr>
</table>

Fichier:Rapport P32 Sultana.pdf

2016-02-22T19:47:39Z

Qsultana :

Projets IMA5 2015/2016

2016-02-22T11:53:09Z

Qsultana : /* Répartition des binômes */

Merci de référencer vos pages de projets ici. Merci aussi d'uniformiser vos formats que ce soit en regardant la présentation des projets déjà créés ou en allant modifier le format des précédents si votre façon de faire vous semble la meilleure. Dans tous les cas un minimum de communication entre les binômes est conseillée.

Toutes les sources doivent être déposées sur notre archive GIT. Le service est disponible à l'URL [https://archives.plil.fr archives.plil.fr]. Connectez-vous avec vos identifiants Polytech'Lille. Sauf indication contraire de vos encadrants, rendez le projet public et mettez le lien sur votre Wiki. Vous pouvez trouver de la documentation sur ce système d'archives sur ce [https://git-scm.com/book/fr/v1 site].

== Répartition des binômes ==

<table border="1">
<tr>
<th>Projet</th>
<th>Elèves</th>
<th>Encadrant Ecole</th>
<th>Rapport décembre</th>
<th>Rapports finaux</th>
<th>Vidéo</th>
</tr>
<tr>
<td>[[P1 Convertisseur DC/DC pour réseau MTDC]]</td>
<td> Mehmet Ilter </td>
<td> Philippe DELARUE </td>
<td> </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P2 Data Logger]]</td>
<td> Hidéo VINOT</td>
<td> Alexandre Boé / Thomas Vantroys </td>
<td> 15/12/2015 12;00</td>
<td> </td>
<td> mercredi 24 février à 10h avec L. Engels</td>
</tr>
<tr>
<td>[[P4 Jukebox multi-pièces]]</td>
<td> Alexandre Jouy / Julien hérin </td>
<td> Rodolphe Astori / Xavier Redon / Alexandre Boé / Thomas Vantroys </td>
<td> [[Fichier:Pre_soutenance_PFE_Jouy_herin.pdf]] </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P9 Système d'hébergement domestique]]</td>
<td> Romain Libaert / Timothée Teneur </td>
<td> Xavier Redon / Alexandre Boé / Thomas Vantroys </td>
<td> 15/12/2015, 10:21, [[Fichier:P9_LIBAERT_TENEUR_DEC15.pdf]]</td>
<td> </td>
<td> RDV L. Engels le 22/02 </td>
</tr>
<tr>
<td>[[P10 LILLIAD: Connected Learning Center | P10 LILLIAD: learning center connecté]]</td>
<td> Mageshwaran Sekar </td>
<td> Alexandre Boé / Thomas Vantroys </td>
<td> 15/12/2015,07:48, [[Fichier:P10_FYP_December_Report_M_SEKAR.pdf]]</td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P11 Spectateur augmenté]]</td>
<td> Teresa Tumbragel </td>
<td> Alexandre Boé / Thomas Vantroys </td>
<td> </td>
<td> [[Fichier:Teresa Tumbragel-Rapport Spectateur Augmente.pdf]] </td>
<td> NA </td>
</tr>
<tr>
<td>[[P12 Capteurs enfouis pour vieillissement du béton]]</td>
<td> JULITA Alex </td>
<td> Alexandre Boé / Thomas Vantroys </td>
<td> </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P14 Localisation dans le corps humain]]</td>
<td> Matthieu Marcadet </td>
<td> Alexandre Boé / Thomas Vantroys </td>
<td> 15/12/2015, 10:52, [[Fichier:Rapport_intermediaire_PFE_Marcadet.pdf]]</td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P18 Meuble intelligent]]</td>
<td> Kevin Colautti / Benjamin Lefort </td>
<td> Rémy Bernard / Alexandre Boé / Xavier Redon / Thomas Vantroys </td>
<td> 14/12/2015, 14:44, [[Fichier:P18_pre_soutenance.pdf]]</td>
<td> </td>
<td> RDV L. Engels le 22/02 </td>
</tr>
<tr>
<td>[[Automatic Soldering System Project|P20 Placeur de composants sur PCB]]</td>
<td> Jean Wasilewski & Pierre Letousey </td>
<td> Xavier Redon / Thomas Vantroys / Alexandre Boé </td>
<td> [[Fichier:P20_ASSP.pdf]]</td>
<td> </td>
<td> Rendez-vous pris avec M. Engels le vendredi 25 Février à 10h </td>
</tr>
<tr>
<td>[[P24 Nuage pour sites Web]]</td>
<td> Jeremie Denechaud / Thibaut Scholaert </td>
<td> Xavier Redon / Thomas Vantroys </td>
<td> 15/12/2015, 12:02, [[Fichier:P24_Denechaud_Scholaert.pdf| Rapport intermédiaire de projet]]</td>
<td> </td>
<td> Fait Maison</td>
</tr>
<tr>
<td>[[P25 Architecture ROS pour des véhicules autonomes intelligents]]</td>
<td> Jean-Michel Tournier / Cyril Smagghe </td>
<td> Vincent Coelen et Rochdi Merzouki </td>
<td> 15/12/2015,09:04, [[Fichier:P25-2015_Smagghe_Tournier_decembre.pdf]]</td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P26 Robot de forgeage et d’usinage]]</td>
<td> Bertrand Yvernault / Louis Thebault </td>
<td> Rochdi Merzouki </td>
<td> 14/12/2015, 17:51</td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P27 Robot de fraiseuse]]</td>
<td> Flavien Royer / Maxime Morisse </td>
<td> Rochdi Merzouki </td>
<td> 14/12/2015, 19:06, [[Fichier:Rapport_Royer_Morisse.pdf]]</td>
<td> </td>
<td> </td>
</tr>

<tr>
<td>[[P30 Thermostat connecté et intelligent]]</td>
<td> TISSOT Elise / TIRABY Céline </td>
<td> Guillaume Renault / Alexandre Boé / Xavier Redon </td>
<td>15/12/2015, 00:35, [[Fichier:Rapport_PFE_TISSOT_TIRABY.pdf‎ ]] </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P32 Récupération d'énergie pour balise BLE]]</td>
<td> Quentin Sultana </td>
<td> Frédéric Giraud / Alexandre Boé / Thomas Vantroys </td>
<td> 13/12/2015, 19:31, [[Fichier:CR Miprojet_Sultana.pdf]]</td>
<td> </td>
<td> RDV L. Engels le 24/02 </td>
</tr>
<tr>
<td>[[P33 Réalisations en faveur de l'accessibilité de jeux vidéos]]</td>
<td> Jérôme Bailet / Mehdi Zeggaï </td>
<td> GAPAS / Laurent Grisoni / Thomas Vantroys </td>
<td> 14/12/2015, 10:54, [[Fichier:PFE_IMA5_Rapport_intermediaire_Bailet_Zeggai.pdf]]</td>
<td> </td>
<td> RDV L. Engels le 25/02 </td>
</tr>
<tr>
<td>[[P35 Robot de test pour le sport de Golf]]</td>
<td> Deborah Saunders </td>
<td> Rochdi Merzouki </td>
<td> 15/12/2015, 12:07</td>
<td> </td>
<td> </td>
</tr>

<tr>
<td>[[P34 Optimisation de trajectoire pour un robot de curiethérapie]]</td>
<td> Sandra HAGE CHEHADE / Thomas DANEL </td>
<td> Vincent COELEN / Rochdi MERZOUKI </td>
<td> 15/12/2015, 12:02</td>
<td> </td>
<td> </td>
</tr>

<tr>
<td>[[P40 Maquette mécatronique durcie d'ascenseur 5 étages]]</td>
<td> Louis CHAUCHARD / Romain IMBERT </td>
<td> Blaise CONRARD </td>
<td> 14/12/2015, 19:21</td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P13 Plateforme expérimentation IOT]]</td>
<td> ROCHE François </td>
<td> Alexandre Boé / Thomas Vantroys </td>
<td> 14/12/2015, 19:37, [[Fichier:PFE_P13_Plateforme_expérimentation_IOT.pdf]] </td>
<td> </td>
<td> RDV L. Engels le 22/02 </td>
</tr>
<tr>
<td>[[Implantation d'un filtre FIR-FX-LMS sur FPGA pour l'annulation de Bruit Acoustique]]</td>
<td> Bown Alexander / Piat Valentin </td>
<td> Alexandre Boé / Thomas Vantroys </td>
<td> NA </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[Pilulier automatique]]</td>
<td> Manouk Simon / Corentin Duplouy </td>
<td> Alexandre Boé / Thomas Vantroys </td>
<td> NA </td>
<td> </td>
<td> RDV L. Engels le 23/02 </td>
</tr>
</table>

P32 Récupération d'énergie pour balise BLE

2016-02-21T17:29:32Z

Qsultana : /* Semaine 20 (22/02/2016) */

P32 Récupération d'énergie pour balise BLE

2016-02-21T17:29:14Z

Qsultana : /* Semaine 20 (22/02/2016) */

== Objectif ==

Mon projet consiste à réaliser un système électronique autonome, composé de différents capteurs et capable de recueillir et de transmettre les données mémorisées vers un système centralisé.

== Etude préalable ==

L’énergie est le point de difficulté dans la réalisation de ce projet. Chaque élément devra être choisi non seulement pour ses performances mais également pour sa faible consommation.

== Organisation générale ==

Le système est organisé autour d’une source d’énergie, d’un contrôleur, de capteurs, de mémoire et d’un protocole de communication.

On cherche à minimiser l'énergie consommée par l'ensemble du système.

[[Fichier:P32Ensemble.PNG|250px|thumb|left|'''Architecture''']]

=== Chaine de l’énergie ===

L’énergie pour ce module autonome est constituée de quatre phases importantes :

[[Fichier:P32Energie.PNG]]

==== La récupération de l'énergie dans l'environnement ====

Il existe de nombreux moyens pour récupérer de l'énergie dans l'environnement. L'objectif est de trouver les sources les plus adaptées à l'environnement de l'application recherchée.

On peut citer:

* La récupération de l'énergie par différence de température

* Les panneaux photovoltaïques

* La récupération de l'énergie des ondes radio

* La Piézoélectricité

Dans ce projet nous utiliserons la piézoélectricité, le module de récupération ayant déjà fait partie d'une étude de IRCICA précédent le projet.

==== Le stockage de l’énergie ====

Le choix du système de stockage de l'énergie constitue une partie importante de la réalisation du système.
La problématique de cette partie sera de déterminer quel type de stockage nous utiliserons : batterie, super-capacité ou un hybride et de les dimensionner.
Il faudra tenir compte des problèmes de décharge partielle influent sur la durée de vie du stockage.

==== Le management/mise en forme de l’énergie ====

L'objectif de cette partie est d'étudier la nécessité de la mise en place d'une régulation tout en préservant des contraintes de consommation très faibles.

==== L'utilisation de l'énergie mise en forme ====

On cherche à minimiser l'énergie consommée par l'ensemble du système.

=== Contrôleur ===

Le microprocesseur : il existe différents types de microprocesseurs. L'objectif est de choisir un support capable de consommer un minimum d'énergie tout en conservant une taille minimale. Nous avons déjà utilisé dans d'autres projets des micro-contrôleurs de type Arduino et Raspberry pie. Ceux-ci ont pour avantage d’être prêts à l'emploi et faciles de prise en main. On peut s’orienter également vers un contrôleur ultra low power comme le STM32L4.

{| class="wikitable centre" width="80%"
|+
|-
! scope=col |
! scope=col | Consommation
! scope=col | Facilité de développement
! scope=col | Miniaturisation
|-
| width="33%" |
<center>Arduino</center>
| width="34%" |
<center>faible à très faible</center>
| width="33%" |
<center>bonne</center>
| width="33%" |
<center>faible</center>
|-
| width="33%" |
<center>Raspberry pi</center>
| width="34%" |
<center>importante</center>
| width="34%" |
<center>très bonne</center>
| width="34%" |
<center>très faible</center>
|-
| width="33%" |
<center>Ultra low power</center>
| width="34%" |
<center>très, très faible</center>
| width="33%" |
<center>difficile</center>
| width="33%" |
<center>forte</center>
|}

=== Capteurs ===

On peut imaginer différents types de capteurs :

* Accéléromètre

* Gyroscope

* Pression atmosphérique et altitude

* Température

* GPS

=== Mémoire ===

Le système doit être autonome et donc conserver un minimum de mesures pour les cas où la connexion est impossible. La mémoire doit être dimensionnée en fonction du nombre de capteurs, l’intervalle d’acquisition et le temps maximum avant connexion au système centralisé.

=== Protocole de communication ===

Un protocole de communication : dans un premier temps, nous nous concentrons sur le protocole BLE (Bluetooth Low Energie). Ce protocole étant standardisé, il nous permettra de recueillir de la documentation et réaliser des tests de consommation rapides.

== Planning prévisionnel ==

[[Fichier:P32Gant.PNG]]

==Suivi de l'avancement du Projet==
===Semaine 1 (28/09/2015)===

* Rencontre avec Monsieur Boe et Monsieur Giraud

* Présentation du projet

* Recherche documentaire

* Etablissement du cahier des charges

===Semaine 2 (05/10/2015)===

Recherche documentaire sur la consommation estimée des différents éléments.

{| class="wikitable centre" width="80%"
|+
|-
! scope=col | '''Contrôleur'''
! scope=col | Consommation Active
! scope=col | Consommation Inactive
! scope=col | Prix
|-
| width="33%" |
<center>Arduino Pro Mini 328 </center>
| width="34%" |
<center> 7mA (1 capteur)</center>
| width="33%" |
<center>4.5µA</center>
| width="33%" |
<center>Disponible</center>
|-
| width="33%" |
<center>STM32L4 Series (STM32L476JE)</center>
| width="34%" |
<center> 100 μA/MHz</center>
| width="33%" |
<center>120 nA</center>
| width="33%" |
<center>$5</center>
|-
| width="33%" |
<center>Raspberry</center>
| width="34%" |
<center> 200mA </center>
| width="33%" |
<center>200mA</center>
| width="33%" |
<center>Disponible</center>
|}

{| class="wikitable centre" width="80%"
|+
|-
! scope=col | '''Module BLE'''
! scope=col | Consommation
! scope=col | Options d'alimentation
! scope=col | Prix
|-
| width="33%" |
<center>BLE Mini</center>
| width="34%" |
<center> 15 mA </center>
| width="33%" |
<center>3.4V à 11V VIN / 5V USB / Coin Cell Battery (2025 or 2032) / 3.7V Li-ion Battery</center>
| width="33%" |
<center>$17</center>
|}

* <s> Le système Mini Arduino/ BLE Mini me semble être un bon compromis entre facilité d’intégration, consommation d'énergie et miniaturisation du système.</s> (Choix à discuter à la réunion du Merdredi 07/10)
* Choix du module RFduino

{| class="wikitable centre" width="80%"
|+
|-
! scope=col | '''Capteurs'''
! scope=col | Modèle
! scope=col | Alimentation min/max
! scope=col | Prix
|-
| width="33%" |
<center>Température</center>
| width="34%" |
<center> TMP36GT9Z </center>
| width="33%" |
<center>2.7V/5.5V</center>
| width="33%" |
<center>1,46 €</center>
|-
| width="33%" |
<center>Accéléromètre</center>
| width="34%" |
<center> ADXL345BCCZ </center>
| width="33%" |
<center>2V/3.6V</center>
| width="33%" |
<center>5,54 €</center>
|-
| width="33%" |
<center>Gyroscope+Accéléromètre</center>
| width="34%" |
<center> MPU-6050</center>
| width="33%" |
<center>2.5V/3.6V</center>
| width="33%" |
<center>15,73 €</center>
|-
| width="33%" |
<center>Pression atmosphérique / Altitude</center>
| width="34%" |
<center> MPL3115A2 </center>
| width="33%" |
<center>1.95V/3.6V</center>
| width="33%" |
<center>2,65 €</center>
|}

* Pour minimiser les pertes on cherche a travailler avec une tension d'alimentation la plus faible possible. Je propose de travailler avec une tension d'alimentation de 3,3V (Validé à discuter à la réunion du Merdredi 07/10)

* Le système de récupération d'énergie fonctionnant sur la base d'un mouvement, j'ai choisi l'ensemble des capteur ci dessus qui me semble être adapté à l'intégration dans un système en mouvement. (Validé à discuter à la réunion du Merdredi 07/10)

* Récupération des modules RFduino, prise en main

===Semaine 3 (12/10/2015)===

* Installation des librairies

* Visualisation d'exemples

* Tests d'implantation du code source du projet P14: Aimant intelligent de la session IMA4: 2014/2015

* Optimisation du code pour la réduction de la consommation d'énergie

* Recherches sur d'autres composants dans l'optique d'une consommation toujours plus faible

{| class="wikitable centre" width="80%"
|+
|-
! scope=col | '''Capteurs'''
! scope=col | Modèle
! scope=col | Alimentation min/max
! scope=col | Prix
! scope=col | Consommation (typ/max)
|-
| width="33%" |
<center>Température</center>
| width="34%" |
<center> STLM20W87F </center>
| width="33%" |
<center>2.4V/5.5V</center>
| width="33%" |
<center> 0,775 € </center>
| width="33%" |
<center> 4.8 μA/8.0 μA </center>
|}

'''Calcul théorique de la consommation énergétique du module BLE + RFD22301'''

Mode "endormi" : ARM CPU Running Current + Output standard drive current = 4 + 0.5 = 4.5mA

Mode "acquisition": ARM CPU Running Current + Output high drive current = 5 + 4 = 9mA

Mode "transmission" : ARM CPU Running Current + Transmit Current + Output standard drive current = 4 + 0.5 + 12 = 16.5mA

http://www.rfduino.com/wp-content/uploads/2014/03/RFD22301.Data_.Sheet_.11.24.13_11.38PM.pdf

'''Code possible du mode "endormi"'''

pinMode(5, INPUT);
RFduino_pinWake(5, HIGH);

RFduino_ULPDelay(INFINITE);
if (RFduino_pinWoke(5))
{
state = ! state;
RFduinoGZLL.sendToHost(state);
}

http://forum.rfduino.com/index.php?topic=385.0

===Semaine 4 (19/10/2015)===

* Réunion du 21/10

* Réalisation de tests

* Ajustement du nombre de capteurs : dans un premier temps on utilisera le capteur de température puis l'accéléromètre

* Discussion sur le bac de test et méthodes de test : résistance de visualisation, chronométrage du temps de transmission, vitesse du processeur

* Réalisation des premiers relevés

===Semaine 5 (26/10/2015)===

* Recherche bibliographique sur les modes d'endormissement du module RFduino

* Essais de codes utilisant un mode d'endormissement plus profond

* Réalisation de graphique de l'énergie utilisée par le module lors de la transmission d'un message par le module BLE.

* Recherches sur des méthodes de programmation pour la diminution de la vitesse processeur

[[Fichier:P32Montage.jpg|250px|thumb|left|'''Montage de test''']]
[[Fichier:P32resultats.jpg|250px|thumb|center|'''Visualisation du courant consommé lors d'envoi toutes les 10ms''']]

* On visualise à l'oscilloscope des pic d'envoi et des pic d'avertissement de la balise BLE, on peut ainsi déduire la puissance nécessaire de chaque action

===Semaine 6 (02/11/2015)===

* Test de diminution de la vitesse processeur

* Réalisation de graphique démontrant l'impact de la réduction de la vitesse processeur sur l'énergie consommée et déduction d'une vitesse optimale pour notre application

* Réunion du 4/11

Définition d'objectifs : Création d'un fichier excel permettant de caractériser les coûts en énergies de chaque étapes de fonctionnement du système.

* Création d'un environnement de test "normé" ( Pour éviter les variations de mesures on réalise un banc et on applique les mêmes conditions de test pour chaque essai)

* Recherche bibliographique sur la norme BLE : recherche du temps maximum entre deux "avertissements" de la balise BLE

===Semaine 7 (09/11/2015)===
* Explication du principe de communication BLE pour l'exploitation des résultats

[[Fichier:Freq.PNG]]

Nous nous intéressons dans notre projet à "l'observateur". Cet objet peut avoir trois états : stand-by, advertising et en communication.

[[Fichier:Brod2.png]]

Dans le mode "Advertising" le système peut :

- Avertir le système récepteur de la proximité d'un capteur

- Avertir de la présence à un appareil souhaitant ce connecter

- Ce reconnecter de façon asynchrone

===Semaine 8 (16/11/2015)===

Analyse en détail d'une trame BLE

[[Fichier:Com.PNG]]

On constate que pendant la durée de la trame il y a un échange entre les deux objets appairé. On s’intéresse ici uniquement aux actions "Slave Tx". Le but étant d'identifier la durée et le courant consommé par ces actions pour obtenir des valeurs en joules.

[[Fichier:SchemaCom.PNG]]

On constate donc deux phases :

- Advertising event

- Connexion event

Nous allons essayer de retrouver et quantifié l'énergie consommé dans ces deux phases.

===Semaine 9 (23/11/2015)===

Lors de cette semaine nous avons effectué des tests en respectant une procédure de test précise. En effet les valeurs des courants que nous relevons sont très petites aussi chaque variation du montage est susceptible de perturber les valeurs.

[[Fichier:P32Conne.jpg|250px|thumb|left|'''Phase connexion''']]

[[Fichier:Avertissement.jpg|250px|thumb|center|'''Phase Advertising''']]

===Semaine 10 (30/11/2015)===

- On cherche a diminuer légèrement la consommation par des modifications logiciel :

Réduction de la puissance de la radio BLE : Diminution de la portée

Augmentation de la fréquence d'advertising : tant que la fréquence d'advetising est inférieure a cette de relevé des capteurs on s'assure que la donnée envoyée est toujours mise à jour.

[[Fichier:Pwl20-envoi.jpg|250px|thumb|left|'''Avec modification logiciel''']]

[[Fichier:Sans-pwlvl.jpg|250px|thumb|center|'''Sans modification logiciel''']]

- On concentre nos résultats dans un tableau récapitulatif en vue du dimensionnement de la batterie du système

[[Fichier:P32tbresul.PNG]]

===Semaine 11 (07/12/2015)===

Tests d'intégration de plusieurs capteur et observations des modification de la consommation des ADC et de la durée/consommation de la transmission.

Réunion de vérification des tests.

Mise en évidence de la dualité consommation d'énergie - Temps de réponse du système

En effet chaque "Advertisement" consomme une quantité d'énergie nous pouvons gérer l'espacement entre ceux-ci mais plus ce temps serra élevé plus il faudra de temps pour ce connecter à ce périphérique.

* Rédaction d'un rapport de test

* Rédaction du rapport de pré soutenance

===Semaine 12 (14/12/2015)===

* Recherches de solutions pour l'amélioration du modèle
* Recherches Matlab pour effectuer une analyse statistique d’avènements aléatoires sur la liaison

===Semaine 13 (04/01/2016)===

*Amélioration du modèle

L’amélioration du modèle est réalisée en tenant compte des facteurs influant sur la qualité de la transmission.

* Utilisation d'un picoscope : appareil permettant l’acquisition sur ordinateur de plusieurs formes d'ondes.
Ainsi grâce à un pico scope utilisé à l’IRCICA j’ai pu relever de nombreux échantillons nécessaires à une étude statistique des surcoûts en énergie.

[[Fichier:Montagemulti.jpg|250px|thumb|left|'''Montage multi récepteur''']]

===Semaine 14 (11/01/2016)===

* Compilation des résultats

* Exploitation Matlab

[[Fichier:Emistbrecap.PNG]]

===Semaine 15 (18/01/2016)===

Principe de fonctionnement du récupérateur d’énergie

Le récupérateur d’énergie fonctionne grâce à un patch piezo. Ce patch est capable de produire un courant à partir de la vélocité d’une impulsion suivant la formule :

[[Fichier:Equapiezo.PNG]]

[[Fichier:Modelepizo.PNG|250px|thumb|left|'''Modèle simplifié du patch piezo''']]

Pour récupérer de l’énergie il est couplé au système suivant :

[[Fichier:montagepiezo.PNG]]

La puissance du système est définie par :

P=V*im

L’énergie s’exprime alors :

[[Fichier:Equaenergie.PNG]]

L’énergie produite par le système est donc dépendante de la tension d’alimentation V de la constante électromécanique N et du choc produit sur le patch piezo.
Une impulsion sur le capteur piezo est de la forme :

La dérivée par rapport au temps de cette impulsion est donc de la forme :

Il est donc important de « fenêtrer » la tension pour ne récupérer que la partie positive.
Ce fenêtrage ainsi que la fréquence de commutation du hacheur sont assurés par un microcontrôleur.

Dans la suite de notre étude nous ne tiendrons pas compte de la consommation de celui-ci.

===Semaine 16 (25/01/2016)===

* Réflexions sur le prototypage

* Présentation du récupérateur

* Mise en place du banc de test

* Premiers relevés

[[Fichier:Montagepiezo.jpg|250px|thumb|left|'''Montage piezo''']]
[[Fichier:Patchpiezo.jpg|250px|thumb|center|'''Patch piezo''']]

===Semaine 17 (01/02/2016)===

Test de la quantité d’énergie récupérée par un patch piezo

Méthodologie :

Channel rouge : Tension aux bornes du patch piezo. Ici on observe une fenêtre de tension de 4,5ms imposée par le microcontrôleur.

Channel vert : Tension aux bornes de la capacité C1 de 220nF
[[Fichier:Diffpot.png|250px|thumb|center|'''Tension patch piezo / Tension C1''']]

On constate qu’un choc sur le patch piezo produit une énergie suivant la formule, E = V * N * Δw
N étant une constante électromécanique, on va faire varier V pour évaluer le gain en énergie. Cependant Δw est généré par un choc d’un stylo sur le patch il n’est donc pas uniforme.
Nous utilisons donc une méthode statistique qui consiste à retirer deux extrémums et faire la moyenne de 10 mesures.

Nous obtenons la courbe suivante :

On constate que la courbe n’est pas linéaire comme l’aurait laissé supposer la formule. En effet jusqu’à 30V elle est linéaire croissante suivant l’équation :

Puis après 50V elle devient quadratique décroissante suivant la formule :

En effet la formule E = V * N * Δw néglige les pertes. Celles-ci deviennent plus importantes à chaque augmentation de la tension d’alimentation.

On obtient donc un point de fonctionnement optimal à 50V pour notre système. Ce qui impose que notre système soit équipé d’une source de tension en conséquence.

===Semaine 18 (08/02/2016)===

*Réalisation de nombreux tests pour confirmation de la caractéristique

[[Fichier:P32Courbe.png]]

*Recherches de solution pour la réalisation d'un convertisseur buck pour passer de la tension récupérée ( ~ 50V ) au récupérateur d'énergie puis au module BLE ( 3.3 V )

*Solution 1 : http://www.ti.com/lit/ds/symlink/tps54060.pdf

*Solution 2: http://fr.farnell.com/stmicroelectronics/l78l33acz/regulateur-3-3v/dp/1467768

===Semaine 19 (15/02/2016)===

*Rédaction du rapport

===Semaine 20 (22/02/2016)===

*édaction du rapport

== Annexes ==

Consommation du STM32L4 Series : http://www.st.com/web/en/catalog/mmc/FM141/SC1169/SS1580?sc=stm32l4

Réduction de la consommation de l'Arduino : http://www.home-automation-community.com/arduino-low-power-how-to-run-atmega328p-for-a-year-on-coin-cell-battery/

Consommation Raspberry : https://www.raspberrypi.org/help/faqs/

Module BLE : http://redbearlab.com/blemini/

Accéléromètre : http://fr.farnell.com/analog-devices/adxl345bccz/accelerometre-3-axes-14lga/dp/1853935

Capteur température : http://fr.farnell.com/analog-devices/tmp36gt9z/capteur-temp-to-92-3/dp/1438760?ost=TMP36GT9Z
ou http://fr.farnell.com/stmicroelectronics/stlm20w87f/capteur-de-temperature-analog/dp/1391131

Accéléromètre + Gyroscope : http://fr.farnell.com/invensense/mpu-6050/gyroscope-accelero-6-axes-i2c/dp/1864742

Altimètre : http://fr.farnell.com/freescale-semiconductor/mpl3115a2/pressure-sensor-20-110kpa-8lga/dp/2009084?ost=MPL3115A2&categoryId=700000004367

Explications norme BLE : chapters.comsoc.org/vancouver/BTLER3.pdf

http://www.argenox.com/bluetooth-low-energy-ble-v4-0-development/library/a-ble-advertising-primer/

----

Fichiers MATLAB

[[Fichier:Recuperation.zip]]

[[Fichier:Recuperation3.zip]]

== Rapport de Mi-projet ==

[[Fichier:CR_Miprojet_Sultana.pdf‎ ]]

P32 Récupération d'énergie pour balise BLE

2016-02-21T17:28:52Z

Qsultana : /* Semaine 17 (01/02/2016) */

== Objectif ==

Mon projet consiste à réaliser un système électronique autonome, composé de différents capteurs et capable de recueillir et de transmettre les données mémorisées vers un système centralisé.

== Etude préalable ==

L’énergie est le point de difficulté dans la réalisation de ce projet. Chaque élément devra être choisi non seulement pour ses performances mais également pour sa faible consommation.

== Organisation générale ==

Le système est organisé autour d’une source d’énergie, d’un contrôleur, de capteurs, de mémoire et d’un protocole de communication.

On cherche à minimiser l'énergie consommée par l'ensemble du système.

[[Fichier:P32Ensemble.PNG|250px|thumb|left|'''Architecture''']]

=== Chaine de l’énergie ===

L’énergie pour ce module autonome est constituée de quatre phases importantes :

[[Fichier:P32Energie.PNG]]

==== La récupération de l'énergie dans l'environnement ====

Il existe de nombreux moyens pour récupérer de l'énergie dans l'environnement. L'objectif est de trouver les sources les plus adaptées à l'environnement de l'application recherchée.

On peut citer:

* La récupération de l'énergie par différence de température

* Les panneaux photovoltaïques

* La récupération de l'énergie des ondes radio

* La Piézoélectricité

Dans ce projet nous utiliserons la piézoélectricité, le module de récupération ayant déjà fait partie d'une étude de IRCICA précédent le projet.

==== Le stockage de l’énergie ====

Le choix du système de stockage de l'énergie constitue une partie importante de la réalisation du système.
La problématique de cette partie sera de déterminer quel type de stockage nous utiliserons : batterie, super-capacité ou un hybride et de les dimensionner.
Il faudra tenir compte des problèmes de décharge partielle influent sur la durée de vie du stockage.

==== Le management/mise en forme de l’énergie ====

L'objectif de cette partie est d'étudier la nécessité de la mise en place d'une régulation tout en préservant des contraintes de consommation très faibles.

==== L'utilisation de l'énergie mise en forme ====

On cherche à minimiser l'énergie consommée par l'ensemble du système.

=== Contrôleur ===

Le microprocesseur : il existe différents types de microprocesseurs. L'objectif est de choisir un support capable de consommer un minimum d'énergie tout en conservant une taille minimale. Nous avons déjà utilisé dans d'autres projets des micro-contrôleurs de type Arduino et Raspberry pie. Ceux-ci ont pour avantage d’être prêts à l'emploi et faciles de prise en main. On peut s’orienter également vers un contrôleur ultra low power comme le STM32L4.

{| class="wikitable centre" width="80%"
|+
|-
! scope=col |
! scope=col | Consommation
! scope=col | Facilité de développement
! scope=col | Miniaturisation
|-
| width="33%" |
<center>Arduino</center>
| width="34%" |
<center>faible à très faible</center>
| width="33%" |
<center>bonne</center>
| width="33%" |
<center>faible</center>
|-
| width="33%" |
<center>Raspberry pi</center>
| width="34%" |
<center>importante</center>
| width="34%" |
<center>très bonne</center>
| width="34%" |
<center>très faible</center>
|-
| width="33%" |
<center>Ultra low power</center>
| width="34%" |
<center>très, très faible</center>
| width="33%" |
<center>difficile</center>
| width="33%" |
<center>forte</center>
|}

=== Capteurs ===

On peut imaginer différents types de capteurs :

* Accéléromètre

* Gyroscope

* Pression atmosphérique et altitude

* Température

* GPS

=== Mémoire ===

Le système doit être autonome et donc conserver un minimum de mesures pour les cas où la connexion est impossible. La mémoire doit être dimensionnée en fonction du nombre de capteurs, l’intervalle d’acquisition et le temps maximum avant connexion au système centralisé.

=== Protocole de communication ===

Un protocole de communication : dans un premier temps, nous nous concentrons sur le protocole BLE (Bluetooth Low Energie). Ce protocole étant standardisé, il nous permettra de recueillir de la documentation et réaliser des tests de consommation rapides.

== Planning prévisionnel ==

[[Fichier:P32Gant.PNG]]

==Suivi de l'avancement du Projet==
===Semaine 1 (28/09/2015)===

* Rencontre avec Monsieur Boe et Monsieur Giraud

* Présentation du projet

* Recherche documentaire

* Etablissement du cahier des charges

===Semaine 2 (05/10/2015)===

Recherche documentaire sur la consommation estimée des différents éléments.

{| class="wikitable centre" width="80%"
|+
|-
! scope=col | '''Contrôleur'''
! scope=col | Consommation Active
! scope=col | Consommation Inactive
! scope=col | Prix
|-
| width="33%" |
<center>Arduino Pro Mini 328 </center>
| width="34%" |
<center> 7mA (1 capteur)</center>
| width="33%" |
<center>4.5µA</center>
| width="33%" |
<center>Disponible</center>
|-
| width="33%" |
<center>STM32L4 Series (STM32L476JE)</center>
| width="34%" |
<center> 100 μA/MHz</center>
| width="33%" |
<center>120 nA</center>
| width="33%" |
<center>$5</center>
|-
| width="33%" |
<center>Raspberry</center>
| width="34%" |
<center> 200mA </center>
| width="33%" |
<center>200mA</center>
| width="33%" |
<center>Disponible</center>
|}

{| class="wikitable centre" width="80%"
|+
|-
! scope=col | '''Module BLE'''
! scope=col | Consommation
! scope=col | Options d'alimentation
! scope=col | Prix
|-
| width="33%" |
<center>BLE Mini</center>
| width="34%" |
<center> 15 mA </center>
| width="33%" |
<center>3.4V à 11V VIN / 5V USB / Coin Cell Battery (2025 or 2032) / 3.7V Li-ion Battery</center>
| width="33%" |
<center>$17</center>
|}

* <s> Le système Mini Arduino/ BLE Mini me semble être un bon compromis entre facilité d’intégration, consommation d'énergie et miniaturisation du système.</s> (Choix à discuter à la réunion du Merdredi 07/10)
* Choix du module RFduino

{| class="wikitable centre" width="80%"
|+
|-
! scope=col | '''Capteurs'''
! scope=col | Modèle
! scope=col | Alimentation min/max
! scope=col | Prix
|-
| width="33%" |
<center>Température</center>
| width="34%" |
<center> TMP36GT9Z </center>
| width="33%" |
<center>2.7V/5.5V</center>
| width="33%" |
<center>1,46 €</center>
|-
| width="33%" |
<center>Accéléromètre</center>
| width="34%" |
<center> ADXL345BCCZ </center>
| width="33%" |
<center>2V/3.6V</center>
| width="33%" |
<center>5,54 €</center>
|-
| width="33%" |
<center>Gyroscope+Accéléromètre</center>
| width="34%" |
<center> MPU-6050</center>
| width="33%" |
<center>2.5V/3.6V</center>
| width="33%" |
<center>15,73 €</center>
|-
| width="33%" |
<center>Pression atmosphérique / Altitude</center>
| width="34%" |
<center> MPL3115A2 </center>
| width="33%" |
<center>1.95V/3.6V</center>
| width="33%" |
<center>2,65 €</center>
|}

* Pour minimiser les pertes on cherche a travailler avec une tension d'alimentation la plus faible possible. Je propose de travailler avec une tension d'alimentation de 3,3V (Validé à discuter à la réunion du Merdredi 07/10)

* Le système de récupération d'énergie fonctionnant sur la base d'un mouvement, j'ai choisi l'ensemble des capteur ci dessus qui me semble être adapté à l'intégration dans un système en mouvement. (Validé à discuter à la réunion du Merdredi 07/10)

* Récupération des modules RFduino, prise en main

===Semaine 3 (12/10/2015)===

* Installation des librairies

* Visualisation d'exemples

* Tests d'implantation du code source du projet P14: Aimant intelligent de la session IMA4: 2014/2015

* Optimisation du code pour la réduction de la consommation d'énergie

* Recherches sur d'autres composants dans l'optique d'une consommation toujours plus faible

{| class="wikitable centre" width="80%"
|+
|-
! scope=col | '''Capteurs'''
! scope=col | Modèle
! scope=col | Alimentation min/max
! scope=col | Prix
! scope=col | Consommation (typ/max)
|-
| width="33%" |
<center>Température</center>
| width="34%" |
<center> STLM20W87F </center>
| width="33%" |
<center>2.4V/5.5V</center>
| width="33%" |
<center> 0,775 € </center>
| width="33%" |
<center> 4.8 μA/8.0 μA </center>
|}

'''Calcul théorique de la consommation énergétique du module BLE + RFD22301'''

Mode "endormi" : ARM CPU Running Current + Output standard drive current = 4 + 0.5 = 4.5mA

Mode "acquisition": ARM CPU Running Current + Output high drive current = 5 + 4 = 9mA

Mode "transmission" : ARM CPU Running Current + Transmit Current + Output standard drive current = 4 + 0.5 + 12 = 16.5mA

http://www.rfduino.com/wp-content/uploads/2014/03/RFD22301.Data_.Sheet_.11.24.13_11.38PM.pdf

'''Code possible du mode "endormi"'''

pinMode(5, INPUT);
RFduino_pinWake(5, HIGH);

RFduino_ULPDelay(INFINITE);
if (RFduino_pinWoke(5))
{
state = ! state;
RFduinoGZLL.sendToHost(state);
}

http://forum.rfduino.com/index.php?topic=385.0

===Semaine 4 (19/10/2015)===

* Réunion du 21/10

* Réalisation de tests

* Ajustement du nombre de capteurs : dans un premier temps on utilisera le capteur de température puis l'accéléromètre

* Discussion sur le bac de test et méthodes de test : résistance de visualisation, chronométrage du temps de transmission, vitesse du processeur

* Réalisation des premiers relevés

===Semaine 5 (26/10/2015)===

* Recherche bibliographique sur les modes d'endormissement du module RFduino

* Essais de codes utilisant un mode d'endormissement plus profond

* Réalisation de graphique de l'énergie utilisée par le module lors de la transmission d'un message par le module BLE.

* Recherches sur des méthodes de programmation pour la diminution de la vitesse processeur

[[Fichier:P32Montage.jpg|250px|thumb|left|'''Montage de test''']]
[[Fichier:P32resultats.jpg|250px|thumb|center|'''Visualisation du courant consommé lors d'envoi toutes les 10ms''']]

* On visualise à l'oscilloscope des pic d'envoi et des pic d'avertissement de la balise BLE, on peut ainsi déduire la puissance nécessaire de chaque action

===Semaine 6 (02/11/2015)===

* Test de diminution de la vitesse processeur

* Réalisation de graphique démontrant l'impact de la réduction de la vitesse processeur sur l'énergie consommée et déduction d'une vitesse optimale pour notre application

* Réunion du 4/11

Définition d'objectifs : Création d'un fichier excel permettant de caractériser les coûts en énergies de chaque étapes de fonctionnement du système.

* Création d'un environnement de test "normé" ( Pour éviter les variations de mesures on réalise un banc et on applique les mêmes conditions de test pour chaque essai)

* Recherche bibliographique sur la norme BLE : recherche du temps maximum entre deux "avertissements" de la balise BLE

===Semaine 7 (09/11/2015)===
* Explication du principe de communication BLE pour l'exploitation des résultats

[[Fichier:Freq.PNG]]

Nous nous intéressons dans notre projet à "l'observateur". Cet objet peut avoir trois états : stand-by, advertising et en communication.

[[Fichier:Brod2.png]]

Dans le mode "Advertising" le système peut :

- Avertir le système récepteur de la proximité d'un capteur

- Avertir de la présence à un appareil souhaitant ce connecter

- Ce reconnecter de façon asynchrone

===Semaine 8 (16/11/2015)===

Analyse en détail d'une trame BLE

[[Fichier:Com.PNG]]

On constate que pendant la durée de la trame il y a un échange entre les deux objets appairé. On s’intéresse ici uniquement aux actions "Slave Tx". Le but étant d'identifier la durée et le courant consommé par ces actions pour obtenir des valeurs en joules.

[[Fichier:SchemaCom.PNG]]

On constate donc deux phases :

- Advertising event

- Connexion event

Nous allons essayer de retrouver et quantifié l'énergie consommé dans ces deux phases.

===Semaine 9 (23/11/2015)===

Lors de cette semaine nous avons effectué des tests en respectant une procédure de test précise. En effet les valeurs des courants que nous relevons sont très petites aussi chaque variation du montage est susceptible de perturber les valeurs.

[[Fichier:P32Conne.jpg|250px|thumb|left|'''Phase connexion''']]

[[Fichier:Avertissement.jpg|250px|thumb|center|'''Phase Advertising''']]

===Semaine 10 (30/11/2015)===

- On cherche a diminuer légèrement la consommation par des modifications logiciel :

Réduction de la puissance de la radio BLE : Diminution de la portée

Augmentation de la fréquence d'advertising : tant que la fréquence d'advetising est inférieure a cette de relevé des capteurs on s'assure que la donnée envoyée est toujours mise à jour.

[[Fichier:Pwl20-envoi.jpg|250px|thumb|left|'''Avec modification logiciel''']]

[[Fichier:Sans-pwlvl.jpg|250px|thumb|center|'''Sans modification logiciel''']]

- On concentre nos résultats dans un tableau récapitulatif en vue du dimensionnement de la batterie du système

[[Fichier:P32tbresul.PNG]]

===Semaine 11 (07/12/2015)===

Tests d'intégration de plusieurs capteur et observations des modification de la consommation des ADC et de la durée/consommation de la transmission.

Réunion de vérification des tests.

Mise en évidence de la dualité consommation d'énergie - Temps de réponse du système

En effet chaque "Advertisement" consomme une quantité d'énergie nous pouvons gérer l'espacement entre ceux-ci mais plus ce temps serra élevé plus il faudra de temps pour ce connecter à ce périphérique.

* Rédaction d'un rapport de test

* Rédaction du rapport de pré soutenance

===Semaine 12 (14/12/2015)===

* Recherches de solutions pour l'amélioration du modèle
* Recherches Matlab pour effectuer une analyse statistique d’avènements aléatoires sur la liaison

===Semaine 13 (04/01/2016)===

*Amélioration du modèle

L’amélioration du modèle est réalisée en tenant compte des facteurs influant sur la qualité de la transmission.

* Utilisation d'un picoscope : appareil permettant l’acquisition sur ordinateur de plusieurs formes d'ondes.
Ainsi grâce à un pico scope utilisé à l’IRCICA j’ai pu relever de nombreux échantillons nécessaires à une étude statistique des surcoûts en énergie.

[[Fichier:Montagemulti.jpg|250px|thumb|left|'''Montage multi récepteur''']]

===Semaine 14 (11/01/2016)===

* Compilation des résultats

* Exploitation Matlab

[[Fichier:Emistbrecap.PNG]]

===Semaine 15 (18/01/2016)===

Principe de fonctionnement du récupérateur d’énergie

Le récupérateur d’énergie fonctionne grâce à un patch piezo. Ce patch est capable de produire un courant à partir de la vélocité d’une impulsion suivant la formule :

[[Fichier:Equapiezo.PNG]]

[[Fichier:Modelepizo.PNG|250px|thumb|left|'''Modèle simplifié du patch piezo''']]

Pour récupérer de l’énergie il est couplé au système suivant :

[[Fichier:montagepiezo.PNG]]

La puissance du système est définie par :

P=V*im

L’énergie s’exprime alors :

[[Fichier:Equaenergie.PNG]]

L’énergie produite par le système est donc dépendante de la tension d’alimentation V de la constante électromécanique N et du choc produit sur le patch piezo.
Une impulsion sur le capteur piezo est de la forme :

La dérivée par rapport au temps de cette impulsion est donc de la forme :

Il est donc important de « fenêtrer » la tension pour ne récupérer que la partie positive.
Ce fenêtrage ainsi que la fréquence de commutation du hacheur sont assurés par un microcontrôleur.

Dans la suite de notre étude nous ne tiendrons pas compte de la consommation de celui-ci.

===Semaine 16 (25/01/2016)===

* Réflexions sur le prototypage

* Présentation du récupérateur

* Mise en place du banc de test

* Premiers relevés

[[Fichier:Montagepiezo.jpg|250px|thumb|left|'''Montage piezo''']]
[[Fichier:Patchpiezo.jpg|250px|thumb|center|'''Patch piezo''']]

===Semaine 17 (01/02/2016)===

Test de la quantité d’énergie récupérée par un patch piezo

Méthodologie :

Channel rouge : Tension aux bornes du patch piezo. Ici on observe une fenêtre de tension de 4,5ms imposée par le microcontrôleur.

Channel vert : Tension aux bornes de la capacité C1 de 220nF
[[Fichier:Diffpot.png|250px|thumb|center|'''Tension patch piezo / Tension C1''']]

On constate qu’un choc sur le patch piezo produit une énergie suivant la formule, E = V * N * Δw
N étant une constante électromécanique, on va faire varier V pour évaluer le gain en énergie. Cependant Δw est généré par un choc d’un stylo sur le patch il n’est donc pas uniforme.
Nous utilisons donc une méthode statistique qui consiste à retirer deux extrémums et faire la moyenne de 10 mesures.

Nous obtenons la courbe suivante :

On constate que la courbe n’est pas linéaire comme l’aurait laissé supposer la formule. En effet jusqu’à 30V elle est linéaire croissante suivant l’équation :

Puis après 50V elle devient quadratique décroissante suivant la formule :

En effet la formule E = V * N * Δw néglige les pertes. Celles-ci deviennent plus importantes à chaque augmentation de la tension d’alimentation.

On obtient donc un point de fonctionnement optimal à 50V pour notre système. Ce qui impose que notre système soit équipé d’une source de tension en conséquence.

===Semaine 18 (08/02/2016)===

*Réalisation de nombreux tests pour confirmation de la caractéristique

[[Fichier:P32Courbe.png]]

*Recherches de solution pour la réalisation d'un convertisseur buck pour passer de la tension récupérée ( ~ 50V ) au récupérateur d'énergie puis au module BLE ( 3.3 V )

*Solution 1 : http://www.ti.com/lit/ds/symlink/tps54060.pdf

*Solution 2: http://fr.farnell.com/stmicroelectronics/l78l33acz/regulateur-3-3v/dp/1467768

===Semaine 19 (15/02/2016)===

*Rédaction du rapport

===Semaine 20 (22/02/2016)===

== Annexes ==

Consommation du STM32L4 Series : http://www.st.com/web/en/catalog/mmc/FM141/SC1169/SS1580?sc=stm32l4

Réduction de la consommation de l'Arduino : http://www.home-automation-community.com/arduino-low-power-how-to-run-atmega328p-for-a-year-on-coin-cell-battery/

Consommation Raspberry : https://www.raspberrypi.org/help/faqs/

Module BLE : http://redbearlab.com/blemini/

Accéléromètre : http://fr.farnell.com/analog-devices/adxl345bccz/accelerometre-3-axes-14lga/dp/1853935

Capteur température : http://fr.farnell.com/analog-devices/tmp36gt9z/capteur-temp-to-92-3/dp/1438760?ost=TMP36GT9Z
ou http://fr.farnell.com/stmicroelectronics/stlm20w87f/capteur-de-temperature-analog/dp/1391131

Accéléromètre + Gyroscope : http://fr.farnell.com/invensense/mpu-6050/gyroscope-accelero-6-axes-i2c/dp/1864742

Altimètre : http://fr.farnell.com/freescale-semiconductor/mpl3115a2/pressure-sensor-20-110kpa-8lga/dp/2009084?ost=MPL3115A2&categoryId=700000004367

Explications norme BLE : chapters.comsoc.org/vancouver/BTLER3.pdf

http://www.argenox.com/bluetooth-low-energy-ble-v4-0-development/library/a-ble-advertising-primer/

----

Fichiers MATLAB

[[Fichier:Recuperation.zip]]

[[Fichier:Recuperation3.zip]]

== Rapport de Mi-projet ==

[[Fichier:CR_Miprojet_Sultana.pdf‎ ]]

P32 Récupération d'énergie pour balise BLE

2016-02-21T17:28:16Z

Qsultana : /* Semaine 17 (01/02/2016) */

== Objectif ==

Mon projet consiste à réaliser un système électronique autonome, composé de différents capteurs et capable de recueillir et de transmettre les données mémorisées vers un système centralisé.

== Etude préalable ==

L’énergie est le point de difficulté dans la réalisation de ce projet. Chaque élément devra être choisi non seulement pour ses performances mais également pour sa faible consommation.

== Organisation générale ==

Le système est organisé autour d’une source d’énergie, d’un contrôleur, de capteurs, de mémoire et d’un protocole de communication.

On cherche à minimiser l'énergie consommée par l'ensemble du système.

[[Fichier:P32Ensemble.PNG|250px|thumb|left|'''Architecture''']]

=== Chaine de l’énergie ===

L’énergie pour ce module autonome est constituée de quatre phases importantes :

[[Fichier:P32Energie.PNG]]

==== La récupération de l'énergie dans l'environnement ====

Il existe de nombreux moyens pour récupérer de l'énergie dans l'environnement. L'objectif est de trouver les sources les plus adaptées à l'environnement de l'application recherchée.

On peut citer:

* La récupération de l'énergie par différence de température

* Les panneaux photovoltaïques

* La récupération de l'énergie des ondes radio

* La Piézoélectricité

Dans ce projet nous utiliserons la piézoélectricité, le module de récupération ayant déjà fait partie d'une étude de IRCICA précédent le projet.

==== Le stockage de l’énergie ====

Le choix du système de stockage de l'énergie constitue une partie importante de la réalisation du système.
La problématique de cette partie sera de déterminer quel type de stockage nous utiliserons : batterie, super-capacité ou un hybride et de les dimensionner.
Il faudra tenir compte des problèmes de décharge partielle influent sur la durée de vie du stockage.

==== Le management/mise en forme de l’énergie ====

L'objectif de cette partie est d'étudier la nécessité de la mise en place d'une régulation tout en préservant des contraintes de consommation très faibles.

==== L'utilisation de l'énergie mise en forme ====

On cherche à minimiser l'énergie consommée par l'ensemble du système.

=== Contrôleur ===

Le microprocesseur : il existe différents types de microprocesseurs. L'objectif est de choisir un support capable de consommer un minimum d'énergie tout en conservant une taille minimale. Nous avons déjà utilisé dans d'autres projets des micro-contrôleurs de type Arduino et Raspberry pie. Ceux-ci ont pour avantage d’être prêts à l'emploi et faciles de prise en main. On peut s’orienter également vers un contrôleur ultra low power comme le STM32L4.

{| class="wikitable centre" width="80%"
|+
|-
! scope=col |
! scope=col | Consommation
! scope=col | Facilité de développement
! scope=col | Miniaturisation
|-
| width="33%" |
<center>Arduino</center>
| width="34%" |
<center>faible à très faible</center>
| width="33%" |
<center>bonne</center>
| width="33%" |
<center>faible</center>
|-
| width="33%" |
<center>Raspberry pi</center>
| width="34%" |
<center>importante</center>
| width="34%" |
<center>très bonne</center>
| width="34%" |
<center>très faible</center>
|-
| width="33%" |
<center>Ultra low power</center>
| width="34%" |
<center>très, très faible</center>
| width="33%" |
<center>difficile</center>
| width="33%" |
<center>forte</center>
|}

=== Capteurs ===

On peut imaginer différents types de capteurs :

* Accéléromètre

* Gyroscope

* Pression atmosphérique et altitude

* Température

* GPS

=== Mémoire ===

Le système doit être autonome et donc conserver un minimum de mesures pour les cas où la connexion est impossible. La mémoire doit être dimensionnée en fonction du nombre de capteurs, l’intervalle d’acquisition et le temps maximum avant connexion au système centralisé.

=== Protocole de communication ===

Un protocole de communication : dans un premier temps, nous nous concentrons sur le protocole BLE (Bluetooth Low Energie). Ce protocole étant standardisé, il nous permettra de recueillir de la documentation et réaliser des tests de consommation rapides.

== Planning prévisionnel ==

[[Fichier:P32Gant.PNG]]

==Suivi de l'avancement du Projet==
===Semaine 1 (28/09/2015)===

* Rencontre avec Monsieur Boe et Monsieur Giraud

* Présentation du projet

* Recherche documentaire

* Etablissement du cahier des charges

===Semaine 2 (05/10/2015)===

Recherche documentaire sur la consommation estimée des différents éléments.

{| class="wikitable centre" width="80%"
|+
|-
! scope=col | '''Contrôleur'''
! scope=col | Consommation Active
! scope=col | Consommation Inactive
! scope=col | Prix
|-
| width="33%" |
<center>Arduino Pro Mini 328 </center>
| width="34%" |
<center> 7mA (1 capteur)</center>
| width="33%" |
<center>4.5µA</center>
| width="33%" |
<center>Disponible</center>
|-
| width="33%" |
<center>STM32L4 Series (STM32L476JE)</center>
| width="34%" |
<center> 100 μA/MHz</center>
| width="33%" |
<center>120 nA</center>
| width="33%" |
<center>$5</center>
|-
| width="33%" |
<center>Raspberry</center>
| width="34%" |
<center> 200mA </center>
| width="33%" |
<center>200mA</center>
| width="33%" |
<center>Disponible</center>
|}

{| class="wikitable centre" width="80%"
|+
|-
! scope=col | '''Module BLE'''
! scope=col | Consommation
! scope=col | Options d'alimentation
! scope=col | Prix
|-
| width="33%" |
<center>BLE Mini</center>
| width="34%" |
<center> 15 mA </center>
| width="33%" |
<center>3.4V à 11V VIN / 5V USB / Coin Cell Battery (2025 or 2032) / 3.7V Li-ion Battery</center>
| width="33%" |
<center>$17</center>
|}

* <s> Le système Mini Arduino/ BLE Mini me semble être un bon compromis entre facilité d’intégration, consommation d'énergie et miniaturisation du système.</s> (Choix à discuter à la réunion du Merdredi 07/10)
* Choix du module RFduino

{| class="wikitable centre" width="80%"
|+
|-
! scope=col | '''Capteurs'''
! scope=col | Modèle
! scope=col | Alimentation min/max
! scope=col | Prix
|-
| width="33%" |
<center>Température</center>
| width="34%" |
<center> TMP36GT9Z </center>
| width="33%" |
<center>2.7V/5.5V</center>
| width="33%" |
<center>1,46 €</center>
|-
| width="33%" |
<center>Accéléromètre</center>
| width="34%" |
<center> ADXL345BCCZ </center>
| width="33%" |
<center>2V/3.6V</center>
| width="33%" |
<center>5,54 €</center>
|-
| width="33%" |
<center>Gyroscope+Accéléromètre</center>
| width="34%" |
<center> MPU-6050</center>
| width="33%" |
<center>2.5V/3.6V</center>
| width="33%" |
<center>15,73 €</center>
|-
| width="33%" |
<center>Pression atmosphérique / Altitude</center>
| width="34%" |
<center> MPL3115A2 </center>
| width="33%" |
<center>1.95V/3.6V</center>
| width="33%" |
<center>2,65 €</center>
|}

* Pour minimiser les pertes on cherche a travailler avec une tension d'alimentation la plus faible possible. Je propose de travailler avec une tension d'alimentation de 3,3V (Validé à discuter à la réunion du Merdredi 07/10)

* Le système de récupération d'énergie fonctionnant sur la base d'un mouvement, j'ai choisi l'ensemble des capteur ci dessus qui me semble être adapté à l'intégration dans un système en mouvement. (Validé à discuter à la réunion du Merdredi 07/10)

* Récupération des modules RFduino, prise en main

===Semaine 3 (12/10/2015)===

* Installation des librairies

* Visualisation d'exemples

* Tests d'implantation du code source du projet P14: Aimant intelligent de la session IMA4: 2014/2015

* Optimisation du code pour la réduction de la consommation d'énergie

* Recherches sur d'autres composants dans l'optique d'une consommation toujours plus faible

{| class="wikitable centre" width="80%"
|+
|-
! scope=col | '''Capteurs'''
! scope=col | Modèle
! scope=col | Alimentation min/max
! scope=col | Prix
! scope=col | Consommation (typ/max)
|-
| width="33%" |
<center>Température</center>
| width="34%" |
<center> STLM20W87F </center>
| width="33%" |
<center>2.4V/5.5V</center>
| width="33%" |
<center> 0,775 € </center>
| width="33%" |
<center> 4.8 μA/8.0 μA </center>
|}

'''Calcul théorique de la consommation énergétique du module BLE + RFD22301'''

Mode "endormi" : ARM CPU Running Current + Output standard drive current = 4 + 0.5 = 4.5mA

Mode "acquisition": ARM CPU Running Current + Output high drive current = 5 + 4 = 9mA

Mode "transmission" : ARM CPU Running Current + Transmit Current + Output standard drive current = 4 + 0.5 + 12 = 16.5mA

http://www.rfduino.com/wp-content/uploads/2014/03/RFD22301.Data_.Sheet_.11.24.13_11.38PM.pdf

'''Code possible du mode "endormi"'''

pinMode(5, INPUT);
RFduino_pinWake(5, HIGH);

RFduino_ULPDelay(INFINITE);
if (RFduino_pinWoke(5))
{
state = ! state;
RFduinoGZLL.sendToHost(state);
}

http://forum.rfduino.com/index.php?topic=385.0

===Semaine 4 (19/10/2015)===

* Réunion du 21/10

* Réalisation de tests

* Ajustement du nombre de capteurs : dans un premier temps on utilisera le capteur de température puis l'accéléromètre

* Discussion sur le bac de test et méthodes de test : résistance de visualisation, chronométrage du temps de transmission, vitesse du processeur

* Réalisation des premiers relevés

===Semaine 5 (26/10/2015)===

* Recherche bibliographique sur les modes d'endormissement du module RFduino

* Essais de codes utilisant un mode d'endormissement plus profond

* Réalisation de graphique de l'énergie utilisée par le module lors de la transmission d'un message par le module BLE.

* Recherches sur des méthodes de programmation pour la diminution de la vitesse processeur

[[Fichier:P32Montage.jpg|250px|thumb|left|'''Montage de test''']]
[[Fichier:P32resultats.jpg|250px|thumb|center|'''Visualisation du courant consommé lors d'envoi toutes les 10ms''']]

* On visualise à l'oscilloscope des pic d'envoi et des pic d'avertissement de la balise BLE, on peut ainsi déduire la puissance nécessaire de chaque action

===Semaine 6 (02/11/2015)===

* Test de diminution de la vitesse processeur

* Réalisation de graphique démontrant l'impact de la réduction de la vitesse processeur sur l'énergie consommée et déduction d'une vitesse optimale pour notre application

* Réunion du 4/11

Définition d'objectifs : Création d'un fichier excel permettant de caractériser les coûts en énergies de chaque étapes de fonctionnement du système.

* Création d'un environnement de test "normé" ( Pour éviter les variations de mesures on réalise un banc et on applique les mêmes conditions de test pour chaque essai)

* Recherche bibliographique sur la norme BLE : recherche du temps maximum entre deux "avertissements" de la balise BLE

===Semaine 7 (09/11/2015)===
* Explication du principe de communication BLE pour l'exploitation des résultats

[[Fichier:Freq.PNG]]

Nous nous intéressons dans notre projet à "l'observateur". Cet objet peut avoir trois états : stand-by, advertising et en communication.

[[Fichier:Brod2.png]]

Dans le mode "Advertising" le système peut :

- Avertir le système récepteur de la proximité d'un capteur

- Avertir de la présence à un appareil souhaitant ce connecter

- Ce reconnecter de façon asynchrone

===Semaine 8 (16/11/2015)===

Analyse en détail d'une trame BLE

[[Fichier:Com.PNG]]

On constate que pendant la durée de la trame il y a un échange entre les deux objets appairé. On s’intéresse ici uniquement aux actions "Slave Tx". Le but étant d'identifier la durée et le courant consommé par ces actions pour obtenir des valeurs en joules.

[[Fichier:SchemaCom.PNG]]

On constate donc deux phases :

- Advertising event

- Connexion event

Nous allons essayer de retrouver et quantifié l'énergie consommé dans ces deux phases.

===Semaine 9 (23/11/2015)===

Lors de cette semaine nous avons effectué des tests en respectant une procédure de test précise. En effet les valeurs des courants que nous relevons sont très petites aussi chaque variation du montage est susceptible de perturber les valeurs.

[[Fichier:P32Conne.jpg|250px|thumb|left|'''Phase connexion''']]

[[Fichier:Avertissement.jpg|250px|thumb|center|'''Phase Advertising''']]

===Semaine 10 (30/11/2015)===

- On cherche a diminuer légèrement la consommation par des modifications logiciel :

Réduction de la puissance de la radio BLE : Diminution de la portée

Augmentation de la fréquence d'advertising : tant que la fréquence d'advetising est inférieure a cette de relevé des capteurs on s'assure que la donnée envoyée est toujours mise à jour.

[[Fichier:Pwl20-envoi.jpg|250px|thumb|left|'''Avec modification logiciel''']]

[[Fichier:Sans-pwlvl.jpg|250px|thumb|center|'''Sans modification logiciel''']]

- On concentre nos résultats dans un tableau récapitulatif en vue du dimensionnement de la batterie du système

[[Fichier:P32tbresul.PNG]]

===Semaine 11 (07/12/2015)===

Tests d'intégration de plusieurs capteur et observations des modification de la consommation des ADC et de la durée/consommation de la transmission.

Réunion de vérification des tests.

Mise en évidence de la dualité consommation d'énergie - Temps de réponse du système

En effet chaque "Advertisement" consomme une quantité d'énergie nous pouvons gérer l'espacement entre ceux-ci mais plus ce temps serra élevé plus il faudra de temps pour ce connecter à ce périphérique.

* Rédaction d'un rapport de test

* Rédaction du rapport de pré soutenance

===Semaine 12 (14/12/2015)===

* Recherches de solutions pour l'amélioration du modèle
* Recherches Matlab pour effectuer une analyse statistique d’avènements aléatoires sur la liaison

===Semaine 13 (04/01/2016)===

*Amélioration du modèle

L’amélioration du modèle est réalisée en tenant compte des facteurs influant sur la qualité de la transmission.

* Utilisation d'un picoscope : appareil permettant l’acquisition sur ordinateur de plusieurs formes d'ondes.
Ainsi grâce à un pico scope utilisé à l’IRCICA j’ai pu relever de nombreux échantillons nécessaires à une étude statistique des surcoûts en énergie.

[[Fichier:Montagemulti.jpg|250px|thumb|left|'''Montage multi récepteur''']]

===Semaine 14 (11/01/2016)===

* Compilation des résultats

* Exploitation Matlab

[[Fichier:Emistbrecap.PNG]]

===Semaine 15 (18/01/2016)===

Principe de fonctionnement du récupérateur d’énergie

Le récupérateur d’énergie fonctionne grâce à un patch piezo. Ce patch est capable de produire un courant à partir de la vélocité d’une impulsion suivant la formule :

[[Fichier:Equapiezo.PNG]]

[[Fichier:Modelepizo.PNG|250px|thumb|left|'''Modèle simplifié du patch piezo''']]

Pour récupérer de l’énergie il est couplé au système suivant :

[[Fichier:montagepiezo.PNG]]

La puissance du système est définie par :

P=V*im

L’énergie s’exprime alors :

[[Fichier:Equaenergie.PNG]]

L’énergie produite par le système est donc dépendante de la tension d’alimentation V de la constante électromécanique N et du choc produit sur le patch piezo.
Une impulsion sur le capteur piezo est de la forme :

La dérivée par rapport au temps de cette impulsion est donc de la forme :

Il est donc important de « fenêtrer » la tension pour ne récupérer que la partie positive.
Ce fenêtrage ainsi que la fréquence de commutation du hacheur sont assurés par un microcontrôleur.

Dans la suite de notre étude nous ne tiendrons pas compte de la consommation de celui-ci.

===Semaine 16 (25/01/2016)===

* Réflexions sur le prototypage

* Présentation du récupérateur

* Mise en place du banc de test

* Premiers relevés

[[Fichier:Montagepiezo.jpg|250px|thumb|left|'''Montage piezo''']]
[[Fichier:Patchpiezo.jpg|250px|thumb|center|'''Patch piezo''']]

===Semaine 17 (01/02/2016)===

Test de la quantité d’énergie récupérée par un patch piezo

Méthodologie :

Channel rouge : Tension aux bornes du patch piezo. Ici on observe une fenêtre de tension de 4,5ms imposée par le microcontrôleur.

Channel vert : Tension aux bornes de la capacité C1 de 220nF
[[Fichier:Diffpot.png|250px|thumb|center|'''Tension patch piezo / Tension C1''']]

On constate qu’un choc sur le patch piezo produit une énergie suivant la formule, E = V * N * Δw
N étant une constante électromécanique, on va faire varier V pour évaluer le gain en énergie. Cependant Δw est généré par un choc d’un stylo sur le patch il n’est donc pas uniforme.
Nous utilisons donc une méthode statistique qui consiste à retirer deux extrémums et faire la moyenne de 10 mesures.

Nous obtenons la courbe suivante :

On constate que la courbe n’est pas linéaire comme l’aurait laissé supposer la formule. En effet jusqu’à 30V elle est linéaire croissante suivant l’équation :

Puis après 50V elle devient quadratique décroissante suivant la formule :

En effet la formule E = V * N * Δw néglige les pertes. Celles-ci deviennent plus importante a chaque augmentation de la tension d’alimentation.

On obtient donc un point de fonctionnement optimal a 30V pour notre système. Ce qui impose que notre système soit équipé d’une source de tension en conséquence.

===Semaine 18 (08/02/2016)===

*Réalisation de nombreux tests pour confirmation de la caractéristique

[[Fichier:P32Courbe.png]]

*Recherches de solution pour la réalisation d'un convertisseur buck pour passer de la tension récupérée ( ~ 50V ) au récupérateur d'énergie puis au module BLE ( 3.3 V )

*Solution 1 : http://www.ti.com/lit/ds/symlink/tps54060.pdf

*Solution 2: http://fr.farnell.com/stmicroelectronics/l78l33acz/regulateur-3-3v/dp/1467768

===Semaine 19 (15/02/2016)===

*Rédaction du rapport

===Semaine 20 (22/02/2016)===

== Annexes ==

Consommation du STM32L4 Series : http://www.st.com/web/en/catalog/mmc/FM141/SC1169/SS1580?sc=stm32l4

Réduction de la consommation de l'Arduino : http://www.home-automation-community.com/arduino-low-power-how-to-run-atmega328p-for-a-year-on-coin-cell-battery/

Consommation Raspberry : https://www.raspberrypi.org/help/faqs/

Module BLE : http://redbearlab.com/blemini/

Accéléromètre : http://fr.farnell.com/analog-devices/adxl345bccz/accelerometre-3-axes-14lga/dp/1853935

Capteur température : http://fr.farnell.com/analog-devices/tmp36gt9z/capteur-temp-to-92-3/dp/1438760?ost=TMP36GT9Z
ou http://fr.farnell.com/stmicroelectronics/stlm20w87f/capteur-de-temperature-analog/dp/1391131

Accéléromètre + Gyroscope : http://fr.farnell.com/invensense/mpu-6050/gyroscope-accelero-6-axes-i2c/dp/1864742

Altimètre : http://fr.farnell.com/freescale-semiconductor/mpl3115a2/pressure-sensor-20-110kpa-8lga/dp/2009084?ost=MPL3115A2&categoryId=700000004367

Explications norme BLE : chapters.comsoc.org/vancouver/BTLER3.pdf

http://www.argenox.com/bluetooth-low-energy-ble-v4-0-development/library/a-ble-advertising-primer/

----

Fichiers MATLAB

[[Fichier:Recuperation.zip]]

[[Fichier:Recuperation3.zip]]

== Rapport de Mi-projet ==

[[Fichier:CR_Miprojet_Sultana.pdf‎ ]]

P32 Récupération d'énergie pour balise BLE

2016-02-21T17:26:35Z

Qsultana : /* Semaine 15 (18/01/2016) */

== Objectif ==

Mon projet consiste à réaliser un système électronique autonome, composé de différents capteurs et capable de recueillir et de transmettre les données mémorisées vers un système centralisé.

== Etude préalable ==

L’énergie est le point de difficulté dans la réalisation de ce projet. Chaque élément devra être choisi non seulement pour ses performances mais également pour sa faible consommation.

== Organisation générale ==

Le système est organisé autour d’une source d’énergie, d’un contrôleur, de capteurs, de mémoire et d’un protocole de communication.

On cherche à minimiser l'énergie consommée par l'ensemble du système.

[[Fichier:P32Ensemble.PNG|250px|thumb|left|'''Architecture''']]

=== Chaine de l’énergie ===

L’énergie pour ce module autonome est constituée de quatre phases importantes :

[[Fichier:P32Energie.PNG]]

==== La récupération de l'énergie dans l'environnement ====

Il existe de nombreux moyens pour récupérer de l'énergie dans l'environnement. L'objectif est de trouver les sources les plus adaptées à l'environnement de l'application recherchée.

On peut citer:

* La récupération de l'énergie par différence de température

* Les panneaux photovoltaïques

* La récupération de l'énergie des ondes radio

* La Piézoélectricité

Dans ce projet nous utiliserons la piézoélectricité, le module de récupération ayant déjà fait partie d'une étude de IRCICA précédent le projet.

==== Le stockage de l’énergie ====

Le choix du système de stockage de l'énergie constitue une partie importante de la réalisation du système.
La problématique de cette partie sera de déterminer quel type de stockage nous utiliserons : batterie, super-capacité ou un hybride et de les dimensionner.
Il faudra tenir compte des problèmes de décharge partielle influent sur la durée de vie du stockage.

==== Le management/mise en forme de l’énergie ====

L'objectif de cette partie est d'étudier la nécessité de la mise en place d'une régulation tout en préservant des contraintes de consommation très faibles.

==== L'utilisation de l'énergie mise en forme ====

On cherche à minimiser l'énergie consommée par l'ensemble du système.

=== Contrôleur ===

Le microprocesseur : il existe différents types de microprocesseurs. L'objectif est de choisir un support capable de consommer un minimum d'énergie tout en conservant une taille minimale. Nous avons déjà utilisé dans d'autres projets des micro-contrôleurs de type Arduino et Raspberry pie. Ceux-ci ont pour avantage d’être prêts à l'emploi et faciles de prise en main. On peut s’orienter également vers un contrôleur ultra low power comme le STM32L4.

{| class="wikitable centre" width="80%"
|+
|-
! scope=col |
! scope=col | Consommation
! scope=col | Facilité de développement
! scope=col | Miniaturisation
|-
| width="33%" |
<center>Arduino</center>
| width="34%" |
<center>faible à très faible</center>
| width="33%" |
<center>bonne</center>
| width="33%" |
<center>faible</center>
|-
| width="33%" |
<center>Raspberry pi</center>
| width="34%" |
<center>importante</center>
| width="34%" |
<center>très bonne</center>
| width="34%" |
<center>très faible</center>
|-
| width="33%" |
<center>Ultra low power</center>
| width="34%" |
<center>très, très faible</center>
| width="33%" |
<center>difficile</center>
| width="33%" |
<center>forte</center>
|}

=== Capteurs ===

On peut imaginer différents types de capteurs :

* Accéléromètre

* Gyroscope

* Pression atmosphérique et altitude

* Température

* GPS

=== Mémoire ===

Le système doit être autonome et donc conserver un minimum de mesures pour les cas où la connexion est impossible. La mémoire doit être dimensionnée en fonction du nombre de capteurs, l’intervalle d’acquisition et le temps maximum avant connexion au système centralisé.

=== Protocole de communication ===

Un protocole de communication : dans un premier temps, nous nous concentrons sur le protocole BLE (Bluetooth Low Energie). Ce protocole étant standardisé, il nous permettra de recueillir de la documentation et réaliser des tests de consommation rapides.

== Planning prévisionnel ==

[[Fichier:P32Gant.PNG]]

==Suivi de l'avancement du Projet==
===Semaine 1 (28/09/2015)===

* Rencontre avec Monsieur Boe et Monsieur Giraud

* Présentation du projet

* Recherche documentaire

* Etablissement du cahier des charges

===Semaine 2 (05/10/2015)===

Recherche documentaire sur la consommation estimée des différents éléments.

{| class="wikitable centre" width="80%"
|+
|-
! scope=col | '''Contrôleur'''
! scope=col | Consommation Active
! scope=col | Consommation Inactive
! scope=col | Prix
|-
| width="33%" |
<center>Arduino Pro Mini 328 </center>
| width="34%" |
<center> 7mA (1 capteur)</center>
| width="33%" |
<center>4.5µA</center>
| width="33%" |
<center>Disponible</center>
|-
| width="33%" |
<center>STM32L4 Series (STM32L476JE)</center>
| width="34%" |
<center> 100 μA/MHz</center>
| width="33%" |
<center>120 nA</center>
| width="33%" |
<center>$5</center>
|-
| width="33%" |
<center>Raspberry</center>
| width="34%" |
<center> 200mA </center>
| width="33%" |
<center>200mA</center>
| width="33%" |
<center>Disponible</center>
|}

{| class="wikitable centre" width="80%"
|+
|-
! scope=col | '''Module BLE'''
! scope=col | Consommation
! scope=col | Options d'alimentation
! scope=col | Prix
|-
| width="33%" |
<center>BLE Mini</center>
| width="34%" |
<center> 15 mA </center>
| width="33%" |
<center>3.4V à 11V VIN / 5V USB / Coin Cell Battery (2025 or 2032) / 3.7V Li-ion Battery</center>
| width="33%" |
<center>$17</center>
|}

* <s> Le système Mini Arduino/ BLE Mini me semble être un bon compromis entre facilité d’intégration, consommation d'énergie et miniaturisation du système.</s> (Choix à discuter à la réunion du Merdredi 07/10)
* Choix du module RFduino

{| class="wikitable centre" width="80%"
|+
|-
! scope=col | '''Capteurs'''
! scope=col | Modèle
! scope=col | Alimentation min/max
! scope=col | Prix
|-
| width="33%" |
<center>Température</center>
| width="34%" |
<center> TMP36GT9Z </center>
| width="33%" |
<center>2.7V/5.5V</center>
| width="33%" |
<center>1,46 €</center>
|-
| width="33%" |
<center>Accéléromètre</center>
| width="34%" |
<center> ADXL345BCCZ </center>
| width="33%" |
<center>2V/3.6V</center>
| width="33%" |
<center>5,54 €</center>
|-
| width="33%" |
<center>Gyroscope+Accéléromètre</center>
| width="34%" |
<center> MPU-6050</center>
| width="33%" |
<center>2.5V/3.6V</center>
| width="33%" |
<center>15,73 €</center>
|-
| width="33%" |
<center>Pression atmosphérique / Altitude</center>
| width="34%" |
<center> MPL3115A2 </center>
| width="33%" |
<center>1.95V/3.6V</center>
| width="33%" |
<center>2,65 €</center>
|}

* Pour minimiser les pertes on cherche a travailler avec une tension d'alimentation la plus faible possible. Je propose de travailler avec une tension d'alimentation de 3,3V (Validé à discuter à la réunion du Merdredi 07/10)

* Le système de récupération d'énergie fonctionnant sur la base d'un mouvement, j'ai choisi l'ensemble des capteur ci dessus qui me semble être adapté à l'intégration dans un système en mouvement. (Validé à discuter à la réunion du Merdredi 07/10)

* Récupération des modules RFduino, prise en main

===Semaine 3 (12/10/2015)===

* Installation des librairies

* Visualisation d'exemples

* Tests d'implantation du code source du projet P14: Aimant intelligent de la session IMA4: 2014/2015

* Optimisation du code pour la réduction de la consommation d'énergie

* Recherches sur d'autres composants dans l'optique d'une consommation toujours plus faible

{| class="wikitable centre" width="80%"
|+
|-
! scope=col | '''Capteurs'''
! scope=col | Modèle
! scope=col | Alimentation min/max
! scope=col | Prix
! scope=col | Consommation (typ/max)
|-
| width="33%" |
<center>Température</center>
| width="34%" |
<center> STLM20W87F </center>
| width="33%" |
<center>2.4V/5.5V</center>
| width="33%" |
<center> 0,775 € </center>
| width="33%" |
<center> 4.8 μA/8.0 μA </center>
|}

'''Calcul théorique de la consommation énergétique du module BLE + RFD22301'''

Mode "endormi" : ARM CPU Running Current + Output standard drive current = 4 + 0.5 = 4.5mA

Mode "acquisition": ARM CPU Running Current + Output high drive current = 5 + 4 = 9mA

Mode "transmission" : ARM CPU Running Current + Transmit Current + Output standard drive current = 4 + 0.5 + 12 = 16.5mA

http://www.rfduino.com/wp-content/uploads/2014/03/RFD22301.Data_.Sheet_.11.24.13_11.38PM.pdf

'''Code possible du mode "endormi"'''

pinMode(5, INPUT);
RFduino_pinWake(5, HIGH);

RFduino_ULPDelay(INFINITE);
if (RFduino_pinWoke(5))
{
state = ! state;
RFduinoGZLL.sendToHost(state);
}

http://forum.rfduino.com/index.php?topic=385.0

===Semaine 4 (19/10/2015)===

* Réunion du 21/10

* Réalisation de tests

* Ajustement du nombre de capteurs : dans un premier temps on utilisera le capteur de température puis l'accéléromètre

* Discussion sur le bac de test et méthodes de test : résistance de visualisation, chronométrage du temps de transmission, vitesse du processeur

* Réalisation des premiers relevés

===Semaine 5 (26/10/2015)===

* Recherche bibliographique sur les modes d'endormissement du module RFduino

* Essais de codes utilisant un mode d'endormissement plus profond

* Réalisation de graphique de l'énergie utilisée par le module lors de la transmission d'un message par le module BLE.

* Recherches sur des méthodes de programmation pour la diminution de la vitesse processeur

[[Fichier:P32Montage.jpg|250px|thumb|left|'''Montage de test''']]
[[Fichier:P32resultats.jpg|250px|thumb|center|'''Visualisation du courant consommé lors d'envoi toutes les 10ms''']]

* On visualise à l'oscilloscope des pic d'envoi et des pic d'avertissement de la balise BLE, on peut ainsi déduire la puissance nécessaire de chaque action

===Semaine 6 (02/11/2015)===

* Test de diminution de la vitesse processeur

* Réalisation de graphique démontrant l'impact de la réduction de la vitesse processeur sur l'énergie consommée et déduction d'une vitesse optimale pour notre application

* Réunion du 4/11

Définition d'objectifs : Création d'un fichier excel permettant de caractériser les coûts en énergies de chaque étapes de fonctionnement du système.

* Création d'un environnement de test "normé" ( Pour éviter les variations de mesures on réalise un banc et on applique les mêmes conditions de test pour chaque essai)

* Recherche bibliographique sur la norme BLE : recherche du temps maximum entre deux "avertissements" de la balise BLE

===Semaine 7 (09/11/2015)===
* Explication du principe de communication BLE pour l'exploitation des résultats

[[Fichier:Freq.PNG]]

Nous nous intéressons dans notre projet à "l'observateur". Cet objet peut avoir trois états : stand-by, advertising et en communication.

[[Fichier:Brod2.png]]

Dans le mode "Advertising" le système peut :

- Avertir le système récepteur de la proximité d'un capteur

- Avertir de la présence à un appareil souhaitant ce connecter

- Ce reconnecter de façon asynchrone

===Semaine 8 (16/11/2015)===

Analyse en détail d'une trame BLE

[[Fichier:Com.PNG]]

On constate que pendant la durée de la trame il y a un échange entre les deux objets appairé. On s’intéresse ici uniquement aux actions "Slave Tx". Le but étant d'identifier la durée et le courant consommé par ces actions pour obtenir des valeurs en joules.

[[Fichier:SchemaCom.PNG]]

On constate donc deux phases :

- Advertising event

- Connexion event

Nous allons essayer de retrouver et quantifié l'énergie consommé dans ces deux phases.

===Semaine 9 (23/11/2015)===

Lors de cette semaine nous avons effectué des tests en respectant une procédure de test précise. En effet les valeurs des courants que nous relevons sont très petites aussi chaque variation du montage est susceptible de perturber les valeurs.

[[Fichier:P32Conne.jpg|250px|thumb|left|'''Phase connexion''']]

[[Fichier:Avertissement.jpg|250px|thumb|center|'''Phase Advertising''']]

===Semaine 10 (30/11/2015)===

- On cherche a diminuer légèrement la consommation par des modifications logiciel :

Réduction de la puissance de la radio BLE : Diminution de la portée

Augmentation de la fréquence d'advertising : tant que la fréquence d'advetising est inférieure a cette de relevé des capteurs on s'assure que la donnée envoyée est toujours mise à jour.

[[Fichier:Pwl20-envoi.jpg|250px|thumb|left|'''Avec modification logiciel''']]

[[Fichier:Sans-pwlvl.jpg|250px|thumb|center|'''Sans modification logiciel''']]

- On concentre nos résultats dans un tableau récapitulatif en vue du dimensionnement de la batterie du système

[[Fichier:P32tbresul.PNG]]

===Semaine 11 (07/12/2015)===

Tests d'intégration de plusieurs capteur et observations des modification de la consommation des ADC et de la durée/consommation de la transmission.

Réunion de vérification des tests.

Mise en évidence de la dualité consommation d'énergie - Temps de réponse du système

En effet chaque "Advertisement" consomme une quantité d'énergie nous pouvons gérer l'espacement entre ceux-ci mais plus ce temps serra élevé plus il faudra de temps pour ce connecter à ce périphérique.

* Rédaction d'un rapport de test

* Rédaction du rapport de pré soutenance

===Semaine 12 (14/12/2015)===

* Recherches de solutions pour l'amélioration du modèle
* Recherches Matlab pour effectuer une analyse statistique d’avènements aléatoires sur la liaison

===Semaine 13 (04/01/2016)===

*Amélioration du modèle

L’amélioration du modèle est réalisée en tenant compte des facteurs influant sur la qualité de la transmission.

* Utilisation d'un picoscope : appareil permettant l’acquisition sur ordinateur de plusieurs formes d'ondes.
Ainsi grâce à un pico scope utilisé à l’IRCICA j’ai pu relever de nombreux échantillons nécessaires à une étude statistique des surcoûts en énergie.

[[Fichier:Montagemulti.jpg|250px|thumb|left|'''Montage multi récepteur''']]

===Semaine 14 (11/01/2016)===

* Compilation des résultats

* Exploitation Matlab

[[Fichier:Emistbrecap.PNG]]

===Semaine 15 (18/01/2016)===

Principe de fonctionnement du récupérateur d’énergie

Le récupérateur d’énergie fonctionne grâce à un patch piezo. Ce patch est capable de produire un courant à partir de la vélocité d’une impulsion suivant la formule :

[[Fichier:Equapiezo.PNG]]

[[Fichier:Modelepizo.PNG|250px|thumb|left|'''Modèle simplifié du patch piezo''']]

Pour récupérer de l’énergie il est couplé au système suivant :

[[Fichier:montagepiezo.PNG]]

La puissance du système est définie par :

P=V*im

L’énergie s’exprime alors :

[[Fichier:Equaenergie.PNG]]

L’énergie produite par le système est donc dépendante de la tension d’alimentation V de la constante électromécanique N et du choc produit sur le patch piezo.
Une impulsion sur le capteur piezo est de la forme :

La dérivée par rapport au temps de cette impulsion est donc de la forme :

Il est donc important de « fenêtrer » la tension pour ne récupérer que la partie positive.
Ce fenêtrage ainsi que la fréquence de commutation du hacheur sont assurés par un microcontrôleur.

Dans la suite de notre étude nous ne tiendrons pas compte de la consommation de celui-ci.

===Semaine 16 (25/01/2016)===

* Réflexions sur le prototypage

* Présentation du récupérateur

* Mise en place du banc de test

* Premiers relevés

[[Fichier:Montagepiezo.jpg|250px|thumb|left|'''Montage piezo''']]
[[Fichier:Patchpiezo.jpg|250px|thumb|center|'''Patch piezo''']]

===Semaine 17 (01/02/2016)===

Test de la quantité d’énergie récupérée par un patch piezo

Méthodologie :

Channel rouge : Tension aux bornes du patch piezo. Ici on observe une fenêtre de tension de 4,5ms imposée par le microcontrôleur.

Channel vert : Tension aux bornes de la capacité C1 de 220nF
[[Fichier:Diffpot.png|250px|thumb|center|'''Tension patch piezo / Tension C1''']]

On constate qu’un choc sur le patch piezo produit une énergie suivent la formule, E = V * N * Δw
N étant une constante électromécanique, on va faire varier V pour évaluer le gain en énergie. Cependant Δw est généré par un choc d’un stylo sur le patch il n’est donc pas uniforme.
Nous utilisons donc une méthode statistique qui consiste à retirer deux extrémum et faire la moyenne de 10 mesures.

Nous obtenons la courbe suivante :

On constate que la courbe n’est pas linéaire comme l’aurai laissé supposer la formule. En effet jusqu’à 30V elle est linéaire croissante suivent l’équation :

Puis après 50V elle devient quadratique décroissante suivent la formule :

En effet la formule E = V * N * Δw néglige les pertes. Celles-ci deviennent plus importante a chaque augmentation de la tension d’alimentation.

On obtient donc un point de fonctionnement optimal a 30V pour notre système. Ce qui impose que notre système soit équipé d’une source de tension en conséquence.

===Semaine 18 (08/02/2016)===

*Réalisation de nombreux tests pour confirmation de la caractéristique

[[Fichier:P32Courbe.png]]

*Recherches de solution pour la réalisation d'un convertisseur buck pour passer de la tension récupérée ( ~ 50V ) au récupérateur d'énergie puis au module BLE ( 3.3 V )

*Solution 1 : http://www.ti.com/lit/ds/symlink/tps54060.pdf

*Solution 2: http://fr.farnell.com/stmicroelectronics/l78l33acz/regulateur-3-3v/dp/1467768

===Semaine 19 (15/02/2016)===

*Rédaction du rapport

===Semaine 20 (22/02/2016)===

== Annexes ==

Consommation du STM32L4 Series : http://www.st.com/web/en/catalog/mmc/FM141/SC1169/SS1580?sc=stm32l4

Réduction de la consommation de l'Arduino : http://www.home-automation-community.com/arduino-low-power-how-to-run-atmega328p-for-a-year-on-coin-cell-battery/

Consommation Raspberry : https://www.raspberrypi.org/help/faqs/

Module BLE : http://redbearlab.com/blemini/

Accéléromètre : http://fr.farnell.com/analog-devices/adxl345bccz/accelerometre-3-axes-14lga/dp/1853935

Capteur température : http://fr.farnell.com/analog-devices/tmp36gt9z/capteur-temp-to-92-3/dp/1438760?ost=TMP36GT9Z
ou http://fr.farnell.com/stmicroelectronics/stlm20w87f/capteur-de-temperature-analog/dp/1391131

Accéléromètre + Gyroscope : http://fr.farnell.com/invensense/mpu-6050/gyroscope-accelero-6-axes-i2c/dp/1864742

Altimètre : http://fr.farnell.com/freescale-semiconductor/mpl3115a2/pressure-sensor-20-110kpa-8lga/dp/2009084?ost=MPL3115A2&categoryId=700000004367

Explications norme BLE : chapters.comsoc.org/vancouver/BTLER3.pdf

http://www.argenox.com/bluetooth-low-energy-ble-v4-0-development/library/a-ble-advertising-primer/

----

Fichiers MATLAB

[[Fichier:Recuperation.zip]]

[[Fichier:Recuperation3.zip]]

== Rapport de Mi-projet ==

[[Fichier:CR_Miprojet_Sultana.pdf‎ ]]

P32 Récupération d'énergie pour balise BLE

2016-02-21T17:24:55Z

Qsultana : /* Semaine 15 (18/01/2016) */

== Objectif ==

Mon projet consiste à réaliser un système électronique autonome, composé de différents capteurs et capable de recueillir et de transmettre les données mémorisées vers un système centralisé.

== Etude préalable ==

L’énergie est le point de difficulté dans la réalisation de ce projet. Chaque élément devra être choisi non seulement pour ses performances mais également pour sa faible consommation.

== Organisation générale ==

Le système est organisé autour d’une source d’énergie, d’un contrôleur, de capteurs, de mémoire et d’un protocole de communication.

On cherche à minimiser l'énergie consommée par l'ensemble du système.

[[Fichier:P32Ensemble.PNG|250px|thumb|left|'''Architecture''']]

=== Chaine de l’énergie ===

L’énergie pour ce module autonome est constituée de quatre phases importantes :

[[Fichier:P32Energie.PNG]]

==== La récupération de l'énergie dans l'environnement ====

Il existe de nombreux moyens pour récupérer de l'énergie dans l'environnement. L'objectif est de trouver les sources les plus adaptées à l'environnement de l'application recherchée.

On peut citer:

* La récupération de l'énergie par différence de température

* Les panneaux photovoltaïques

* La récupération de l'énergie des ondes radio

* La Piézoélectricité

Dans ce projet nous utiliserons la piézoélectricité, le module de récupération ayant déjà fait partie d'une étude de IRCICA précédent le projet.

==== Le stockage de l’énergie ====

Le choix du système de stockage de l'énergie constitue une partie importante de la réalisation du système.
La problématique de cette partie sera de déterminer quel type de stockage nous utiliserons : batterie, super-capacité ou un hybride et de les dimensionner.
Il faudra tenir compte des problèmes de décharge partielle influent sur la durée de vie du stockage.

==== Le management/mise en forme de l’énergie ====

L'objectif de cette partie est d'étudier la nécessité de la mise en place d'une régulation tout en préservant des contraintes de consommation très faibles.

==== L'utilisation de l'énergie mise en forme ====

On cherche à minimiser l'énergie consommée par l'ensemble du système.

=== Contrôleur ===

Le microprocesseur : il existe différents types de microprocesseurs. L'objectif est de choisir un support capable de consommer un minimum d'énergie tout en conservant une taille minimale. Nous avons déjà utilisé dans d'autres projets des micro-contrôleurs de type Arduino et Raspberry pie. Ceux-ci ont pour avantage d’être prêts à l'emploi et faciles de prise en main. On peut s’orienter également vers un contrôleur ultra low power comme le STM32L4.

{| class="wikitable centre" width="80%"
|+
|-
! scope=col |
! scope=col | Consommation
! scope=col | Facilité de développement
! scope=col | Miniaturisation
|-
| width="33%" |
<center>Arduino</center>
| width="34%" |
<center>faible à très faible</center>
| width="33%" |
<center>bonne</center>
| width="33%" |
<center>faible</center>
|-
| width="33%" |
<center>Raspberry pi</center>
| width="34%" |
<center>importante</center>
| width="34%" |
<center>très bonne</center>
| width="34%" |
<center>très faible</center>
|-
| width="33%" |
<center>Ultra low power</center>
| width="34%" |
<center>très, très faible</center>
| width="33%" |
<center>difficile</center>
| width="33%" |
<center>forte</center>
|}

=== Capteurs ===

On peut imaginer différents types de capteurs :

* Accéléromètre

* Gyroscope

* Pression atmosphérique et altitude

* Température

* GPS

=== Mémoire ===

Le système doit être autonome et donc conserver un minimum de mesures pour les cas où la connexion est impossible. La mémoire doit être dimensionnée en fonction du nombre de capteurs, l’intervalle d’acquisition et le temps maximum avant connexion au système centralisé.

=== Protocole de communication ===

Un protocole de communication : dans un premier temps, nous nous concentrons sur le protocole BLE (Bluetooth Low Energie). Ce protocole étant standardisé, il nous permettra de recueillir de la documentation et réaliser des tests de consommation rapides.

== Planning prévisionnel ==

[[Fichier:P32Gant.PNG]]

==Suivi de l'avancement du Projet==
===Semaine 1 (28/09/2015)===

* Rencontre avec Monsieur Boe et Monsieur Giraud

* Présentation du projet

* Recherche documentaire

* Etablissement du cahier des charges

===Semaine 2 (05/10/2015)===

Recherche documentaire sur la consommation estimée des différents éléments.

{| class="wikitable centre" width="80%"
|+
|-
! scope=col | '''Contrôleur'''
! scope=col | Consommation Active
! scope=col | Consommation Inactive
! scope=col | Prix
|-
| width="33%" |
<center>Arduino Pro Mini 328 </center>
| width="34%" |
<center> 7mA (1 capteur)</center>
| width="33%" |
<center>4.5µA</center>
| width="33%" |
<center>Disponible</center>
|-
| width="33%" |
<center>STM32L4 Series (STM32L476JE)</center>
| width="34%" |
<center> 100 μA/MHz</center>
| width="33%" |
<center>120 nA</center>
| width="33%" |
<center>$5</center>
|-
| width="33%" |
<center>Raspberry</center>
| width="34%" |
<center> 200mA </center>
| width="33%" |
<center>200mA</center>
| width="33%" |
<center>Disponible</center>
|}

{| class="wikitable centre" width="80%"
|+
|-
! scope=col | '''Module BLE'''
! scope=col | Consommation
! scope=col | Options d'alimentation
! scope=col | Prix
|-
| width="33%" |
<center>BLE Mini</center>
| width="34%" |
<center> 15 mA </center>
| width="33%" |
<center>3.4V à 11V VIN / 5V USB / Coin Cell Battery (2025 or 2032) / 3.7V Li-ion Battery</center>
| width="33%" |
<center>$17</center>
|}

* <s> Le système Mini Arduino/ BLE Mini me semble être un bon compromis entre facilité d’intégration, consommation d'énergie et miniaturisation du système.</s> (Choix à discuter à la réunion du Merdredi 07/10)
* Choix du module RFduino

{| class="wikitable centre" width="80%"
|+
|-
! scope=col | '''Capteurs'''
! scope=col | Modèle
! scope=col | Alimentation min/max
! scope=col | Prix
|-
| width="33%" |
<center>Température</center>
| width="34%" |
<center> TMP36GT9Z </center>
| width="33%" |
<center>2.7V/5.5V</center>
| width="33%" |
<center>1,46 €</center>
|-
| width="33%" |
<center>Accéléromètre</center>
| width="34%" |
<center> ADXL345BCCZ </center>
| width="33%" |
<center>2V/3.6V</center>
| width="33%" |
<center>5,54 €</center>
|-
| width="33%" |
<center>Gyroscope+Accéléromètre</center>
| width="34%" |
<center> MPU-6050</center>
| width="33%" |
<center>2.5V/3.6V</center>
| width="33%" |
<center>15,73 €</center>
|-
| width="33%" |
<center>Pression atmosphérique / Altitude</center>
| width="34%" |
<center> MPL3115A2 </center>
| width="33%" |
<center>1.95V/3.6V</center>
| width="33%" |
<center>2,65 €</center>
|}

* Pour minimiser les pertes on cherche a travailler avec une tension d'alimentation la plus faible possible. Je propose de travailler avec une tension d'alimentation de 3,3V (Validé à discuter à la réunion du Merdredi 07/10)

* Le système de récupération d'énergie fonctionnant sur la base d'un mouvement, j'ai choisi l'ensemble des capteur ci dessus qui me semble être adapté à l'intégration dans un système en mouvement. (Validé à discuter à la réunion du Merdredi 07/10)

* Récupération des modules RFduino, prise en main

===Semaine 3 (12/10/2015)===

* Installation des librairies

* Visualisation d'exemples

* Tests d'implantation du code source du projet P14: Aimant intelligent de la session IMA4: 2014/2015

* Optimisation du code pour la réduction de la consommation d'énergie

* Recherches sur d'autres composants dans l'optique d'une consommation toujours plus faible

{| class="wikitable centre" width="80%"
|+
|-
! scope=col | '''Capteurs'''
! scope=col | Modèle
! scope=col | Alimentation min/max
! scope=col | Prix
! scope=col | Consommation (typ/max)
|-
| width="33%" |
<center>Température</center>
| width="34%" |
<center> STLM20W87F </center>
| width="33%" |
<center>2.4V/5.5V</center>
| width="33%" |
<center> 0,775 € </center>
| width="33%" |
<center> 4.8 μA/8.0 μA </center>
|}

'''Calcul théorique de la consommation énergétique du module BLE + RFD22301'''

Mode "endormi" : ARM CPU Running Current + Output standard drive current = 4 + 0.5 = 4.5mA

Mode "acquisition": ARM CPU Running Current + Output high drive current = 5 + 4 = 9mA

Mode "transmission" : ARM CPU Running Current + Transmit Current + Output standard drive current = 4 + 0.5 + 12 = 16.5mA

http://www.rfduino.com/wp-content/uploads/2014/03/RFD22301.Data_.Sheet_.11.24.13_11.38PM.pdf

'''Code possible du mode "endormi"'''

pinMode(5, INPUT);
RFduino_pinWake(5, HIGH);

RFduino_ULPDelay(INFINITE);
if (RFduino_pinWoke(5))
{
state = ! state;
RFduinoGZLL.sendToHost(state);
}

http://forum.rfduino.com/index.php?topic=385.0

===Semaine 4 (19/10/2015)===

* Réunion du 21/10

* Réalisation de tests

* Ajustement du nombre de capteurs : dans un premier temps on utilisera le capteur de température puis l'accéléromètre

* Discussion sur le bac de test et méthodes de test : résistance de visualisation, chronométrage du temps de transmission, vitesse du processeur

* Réalisation des premiers relevés

===Semaine 5 (26/10/2015)===

* Recherche bibliographique sur les modes d'endormissement du module RFduino

* Essais de codes utilisant un mode d'endormissement plus profond

* Réalisation de graphique de l'énergie utilisée par le module lors de la transmission d'un message par le module BLE.

* Recherches sur des méthodes de programmation pour la diminution de la vitesse processeur

[[Fichier:P32Montage.jpg|250px|thumb|left|'''Montage de test''']]
[[Fichier:P32resultats.jpg|250px|thumb|center|'''Visualisation du courant consommé lors d'envoi toutes les 10ms''']]

* On visualise à l'oscilloscope des pic d'envoi et des pic d'avertissement de la balise BLE, on peut ainsi déduire la puissance nécessaire de chaque action

===Semaine 6 (02/11/2015)===

* Test de diminution de la vitesse processeur

* Réalisation de graphique démontrant l'impact de la réduction de la vitesse processeur sur l'énergie consommée et déduction d'une vitesse optimale pour notre application

* Réunion du 4/11

Définition d'objectifs : Création d'un fichier excel permettant de caractériser les coûts en énergies de chaque étapes de fonctionnement du système.

* Création d'un environnement de test "normé" ( Pour éviter les variations de mesures on réalise un banc et on applique les mêmes conditions de test pour chaque essai)

* Recherche bibliographique sur la norme BLE : recherche du temps maximum entre deux "avertissements" de la balise BLE

===Semaine 7 (09/11/2015)===
* Explication du principe de communication BLE pour l'exploitation des résultats

[[Fichier:Freq.PNG]]

Nous nous intéressons dans notre projet à "l'observateur". Cet objet peut avoir trois états : stand-by, advertising et en communication.

[[Fichier:Brod2.png]]

Dans le mode "Advertising" le système peut :

- Avertir le système récepteur de la proximité d'un capteur

- Avertir de la présence à un appareil souhaitant ce connecter

- Ce reconnecter de façon asynchrone

===Semaine 8 (16/11/2015)===

Analyse en détail d'une trame BLE

[[Fichier:Com.PNG]]

On constate que pendant la durée de la trame il y a un échange entre les deux objets appairé. On s’intéresse ici uniquement aux actions "Slave Tx". Le but étant d'identifier la durée et le courant consommé par ces actions pour obtenir des valeurs en joules.

[[Fichier:SchemaCom.PNG]]

On constate donc deux phases :

- Advertising event

- Connexion event

Nous allons essayer de retrouver et quantifié l'énergie consommé dans ces deux phases.

===Semaine 9 (23/11/2015)===

Lors de cette semaine nous avons effectué des tests en respectant une procédure de test précise. En effet les valeurs des courants que nous relevons sont très petites aussi chaque variation du montage est susceptible de perturber les valeurs.

[[Fichier:P32Conne.jpg|250px|thumb|left|'''Phase connexion''']]

[[Fichier:Avertissement.jpg|250px|thumb|center|'''Phase Advertising''']]

===Semaine 10 (30/11/2015)===

- On cherche a diminuer légèrement la consommation par des modifications logiciel :

Réduction de la puissance de la radio BLE : Diminution de la portée

Augmentation de la fréquence d'advertising : tant que la fréquence d'advetising est inférieure a cette de relevé des capteurs on s'assure que la donnée envoyée est toujours mise à jour.

[[Fichier:Pwl20-envoi.jpg|250px|thumb|left|'''Avec modification logiciel''']]

[[Fichier:Sans-pwlvl.jpg|250px|thumb|center|'''Sans modification logiciel''']]

- On concentre nos résultats dans un tableau récapitulatif en vue du dimensionnement de la batterie du système

[[Fichier:P32tbresul.PNG]]

===Semaine 11 (07/12/2015)===

Tests d'intégration de plusieurs capteur et observations des modification de la consommation des ADC et de la durée/consommation de la transmission.

Réunion de vérification des tests.

Mise en évidence de la dualité consommation d'énergie - Temps de réponse du système

En effet chaque "Advertisement" consomme une quantité d'énergie nous pouvons gérer l'espacement entre ceux-ci mais plus ce temps serra élevé plus il faudra de temps pour ce connecter à ce périphérique.

* Rédaction d'un rapport de test

* Rédaction du rapport de pré soutenance

===Semaine 12 (14/12/2015)===

* Recherches de solutions pour l'amélioration du modèle
* Recherches Matlab pour effectuer une analyse statistique d’avènements aléatoires sur la liaison

===Semaine 13 (04/01/2016)===

*Amélioration du modèle

L’amélioration du modèle est réalisée en tenant compte des facteurs influant sur la qualité de la transmission.

* Utilisation d'un picoscope : appareil permettant l’acquisition sur ordinateur de plusieurs formes d'ondes.
Ainsi grâce à un pico scope utilisé à l’IRCICA j’ai pu relever de nombreux échantillons nécessaires à une étude statistique des surcoûts en énergie.

[[Fichier:Montagemulti.jpg|250px|thumb|left|'''Montage multi récepteur''']]

===Semaine 14 (11/01/2016)===

* Compilation des résultats

* Exploitation Matlab

[[Fichier:Emistbrecap.PNG]]

===Semaine 15 (18/01/2016)===

Principe de fonctionnement du récupérateur d’énergie

Le récupérateur d’énergie fonctionne grâce à un patch piezo. Ce patch est capable de produire un courant à partir de la vélocité d’une impulsion suivant la formule :

[[Fichier:Equapiezo.PNG]]

[[Fichier:Modelepizo.PNG|250px|thumb|left|'''Modèle simplifié du patch piezo''']]

Pour récupérer de l’énergie il est couplé au système suivent :

[[Fichier:montagepiezo.PNG]]

La puissance du système est définie par :

P=V*im

L’énergie s’exprime alors :

[[Fichier:Equaenergie.PNG]]

L’énergie produite par le système est donc dépendante de la tension d’alimentation V de la constante électromécanique N et du choc produit sur le patch piezo.
Une impulsion sur le capteur piezo est de la forme :

La dérivée par rapport au temps de cette impulsion est donc de la forme :

Il est donc important de « fenêtrer » la tension pour ne récupérer que la partie positive.
Ce fenêtrage ainsi que la fréquence de commutation du hacheur est assurée par un microcontrôleur.

Dans la suite de notre étude nous ne tiendrons pas compte de la consommation de celui-ci.

===Semaine 16 (25/01/2016)===

* Réflexions sur le prototypage

* Présentation du récupérateur

* Mise en place du banc de test

* Premiers relevés

[[Fichier:Montagepiezo.jpg|250px|thumb|left|'''Montage piezo''']]
[[Fichier:Patchpiezo.jpg|250px|thumb|center|'''Patch piezo''']]

===Semaine 17 (01/02/2016)===

Test de la quantité d’énergie récupérée par un patch piezo

Méthodologie :

Channel rouge : Tension aux bornes du patch piezo. Ici on observe une fenêtre de tension de 4,5ms imposée par le microcontrôleur.

Channel vert : Tension aux bornes de la capacité C1 de 220nF
[[Fichier:Diffpot.png|250px|thumb|center|'''Tension patch piezo / Tension C1''']]

On constate qu’un choc sur le patch piezo produit une énergie suivent la formule, E = V * N * Δw
N étant une constante électromécanique, on va faire varier V pour évaluer le gain en énergie. Cependant Δw est généré par un choc d’un stylo sur le patch il n’est donc pas uniforme.
Nous utilisons donc une méthode statistique qui consiste à retirer deux extrémum et faire la moyenne de 10 mesures.

Nous obtenons la courbe suivante :

On constate que la courbe n’est pas linéaire comme l’aurai laissé supposer la formule. En effet jusqu’à 30V elle est linéaire croissante suivent l’équation :

Puis après 50V elle devient quadratique décroissante suivent la formule :

En effet la formule E = V * N * Δw néglige les pertes. Celles-ci deviennent plus importante a chaque augmentation de la tension d’alimentation.

On obtient donc un point de fonctionnement optimal a 30V pour notre système. Ce qui impose que notre système soit équipé d’une source de tension en conséquence.

===Semaine 18 (08/02/2016)===

*Réalisation de nombreux tests pour confirmation de la caractéristique

[[Fichier:P32Courbe.png]]

*Recherches de solution pour la réalisation d'un convertisseur buck pour passer de la tension récupérée ( ~ 50V ) au récupérateur d'énergie puis au module BLE ( 3.3 V )

*Solution 1 : http://www.ti.com/lit/ds/symlink/tps54060.pdf

*Solution 2: http://fr.farnell.com/stmicroelectronics/l78l33acz/regulateur-3-3v/dp/1467768

===Semaine 19 (15/02/2016)===

*Rédaction du rapport

===Semaine 20 (22/02/2016)===

== Annexes ==

Consommation du STM32L4 Series : http://www.st.com/web/en/catalog/mmc/FM141/SC1169/SS1580?sc=stm32l4

Réduction de la consommation de l'Arduino : http://www.home-automation-community.com/arduino-low-power-how-to-run-atmega328p-for-a-year-on-coin-cell-battery/

Consommation Raspberry : https://www.raspberrypi.org/help/faqs/

Module BLE : http://redbearlab.com/blemini/

Accéléromètre : http://fr.farnell.com/analog-devices/adxl345bccz/accelerometre-3-axes-14lga/dp/1853935

Capteur température : http://fr.farnell.com/analog-devices/tmp36gt9z/capteur-temp-to-92-3/dp/1438760?ost=TMP36GT9Z
ou http://fr.farnell.com/stmicroelectronics/stlm20w87f/capteur-de-temperature-analog/dp/1391131

Accéléromètre + Gyroscope : http://fr.farnell.com/invensense/mpu-6050/gyroscope-accelero-6-axes-i2c/dp/1864742

Altimètre : http://fr.farnell.com/freescale-semiconductor/mpl3115a2/pressure-sensor-20-110kpa-8lga/dp/2009084?ost=MPL3115A2&categoryId=700000004367

Explications norme BLE : chapters.comsoc.org/vancouver/BTLER3.pdf

http://www.argenox.com/bluetooth-low-energy-ble-v4-0-development/library/a-ble-advertising-primer/

----

Fichiers MATLAB

[[Fichier:Recuperation.zip]]

[[Fichier:Recuperation3.zip]]

== Rapport de Mi-projet ==

[[Fichier:CR_Miprojet_Sultana.pdf‎ ]]

P32 Récupération d'énergie pour balise BLE

2016-02-21T17:24:26Z

Qsultana : /* Semaine 13 (04/01/2016) */

== Objectif ==

Mon projet consiste à réaliser un système électronique autonome, composé de différents capteurs et capable de recueillir et de transmettre les données mémorisées vers un système centralisé.

== Etude préalable ==

L’énergie est le point de difficulté dans la réalisation de ce projet. Chaque élément devra être choisi non seulement pour ses performances mais également pour sa faible consommation.

== Organisation générale ==

Le système est organisé autour d’une source d’énergie, d’un contrôleur, de capteurs, de mémoire et d’un protocole de communication.

On cherche à minimiser l'énergie consommée par l'ensemble du système.

[[Fichier:P32Ensemble.PNG|250px|thumb|left|'''Architecture''']]

=== Chaine de l’énergie ===

L’énergie pour ce module autonome est constituée de quatre phases importantes :

[[Fichier:P32Energie.PNG]]

==== La récupération de l'énergie dans l'environnement ====

Il existe de nombreux moyens pour récupérer de l'énergie dans l'environnement. L'objectif est de trouver les sources les plus adaptées à l'environnement de l'application recherchée.

On peut citer:

* La récupération de l'énergie par différence de température

* Les panneaux photovoltaïques

* La récupération de l'énergie des ondes radio

* La Piézoélectricité

Dans ce projet nous utiliserons la piézoélectricité, le module de récupération ayant déjà fait partie d'une étude de IRCICA précédent le projet.

==== Le stockage de l’énergie ====

Le choix du système de stockage de l'énergie constitue une partie importante de la réalisation du système.
La problématique de cette partie sera de déterminer quel type de stockage nous utiliserons : batterie, super-capacité ou un hybride et de les dimensionner.
Il faudra tenir compte des problèmes de décharge partielle influent sur la durée de vie du stockage.

==== Le management/mise en forme de l’énergie ====

L'objectif de cette partie est d'étudier la nécessité de la mise en place d'une régulation tout en préservant des contraintes de consommation très faibles.

==== L'utilisation de l'énergie mise en forme ====

On cherche à minimiser l'énergie consommée par l'ensemble du système.

=== Contrôleur ===

Le microprocesseur : il existe différents types de microprocesseurs. L'objectif est de choisir un support capable de consommer un minimum d'énergie tout en conservant une taille minimale. Nous avons déjà utilisé dans d'autres projets des micro-contrôleurs de type Arduino et Raspberry pie. Ceux-ci ont pour avantage d’être prêts à l'emploi et faciles de prise en main. On peut s’orienter également vers un contrôleur ultra low power comme le STM32L4.

{| class="wikitable centre" width="80%"
|+
|-
! scope=col |
! scope=col | Consommation
! scope=col | Facilité de développement
! scope=col | Miniaturisation
|-
| width="33%" |
<center>Arduino</center>
| width="34%" |
<center>faible à très faible</center>
| width="33%" |
<center>bonne</center>
| width="33%" |
<center>faible</center>
|-
| width="33%" |
<center>Raspberry pi</center>
| width="34%" |
<center>importante</center>
| width="34%" |
<center>très bonne</center>
| width="34%" |
<center>très faible</center>
|-
| width="33%" |
<center>Ultra low power</center>
| width="34%" |
<center>très, très faible</center>
| width="33%" |
<center>difficile</center>
| width="33%" |
<center>forte</center>
|}

=== Capteurs ===

On peut imaginer différents types de capteurs :

* Accéléromètre

* Gyroscope

* Pression atmosphérique et altitude

* Température

* GPS

=== Mémoire ===

Le système doit être autonome et donc conserver un minimum de mesures pour les cas où la connexion est impossible. La mémoire doit être dimensionnée en fonction du nombre de capteurs, l’intervalle d’acquisition et le temps maximum avant connexion au système centralisé.

=== Protocole de communication ===

Un protocole de communication : dans un premier temps, nous nous concentrons sur le protocole BLE (Bluetooth Low Energie). Ce protocole étant standardisé, il nous permettra de recueillir de la documentation et réaliser des tests de consommation rapides.

== Planning prévisionnel ==

[[Fichier:P32Gant.PNG]]

==Suivi de l'avancement du Projet==
===Semaine 1 (28/09/2015)===

* Rencontre avec Monsieur Boe et Monsieur Giraud

* Présentation du projet

* Recherche documentaire

* Etablissement du cahier des charges

===Semaine 2 (05/10/2015)===

Recherche documentaire sur la consommation estimée des différents éléments.

{| class="wikitable centre" width="80%"
|+
|-
! scope=col | '''Contrôleur'''
! scope=col | Consommation Active
! scope=col | Consommation Inactive
! scope=col | Prix
|-
| width="33%" |
<center>Arduino Pro Mini 328 </center>
| width="34%" |
<center> 7mA (1 capteur)</center>
| width="33%" |
<center>4.5µA</center>
| width="33%" |
<center>Disponible</center>
|-
| width="33%" |
<center>STM32L4 Series (STM32L476JE)</center>
| width="34%" |
<center> 100 μA/MHz</center>
| width="33%" |
<center>120 nA</center>
| width="33%" |
<center>$5</center>
|-
| width="33%" |
<center>Raspberry</center>
| width="34%" |
<center> 200mA </center>
| width="33%" |
<center>200mA</center>
| width="33%" |
<center>Disponible</center>
|}

{| class="wikitable centre" width="80%"
|+
|-
! scope=col | '''Module BLE'''
! scope=col | Consommation
! scope=col | Options d'alimentation
! scope=col | Prix
|-
| width="33%" |
<center>BLE Mini</center>
| width="34%" |
<center> 15 mA </center>
| width="33%" |
<center>3.4V à 11V VIN / 5V USB / Coin Cell Battery (2025 or 2032) / 3.7V Li-ion Battery</center>
| width="33%" |
<center>$17</center>
|}

* <s> Le système Mini Arduino/ BLE Mini me semble être un bon compromis entre facilité d’intégration, consommation d'énergie et miniaturisation du système.</s> (Choix à discuter à la réunion du Merdredi 07/10)
* Choix du module RFduino

{| class="wikitable centre" width="80%"
|+
|-
! scope=col | '''Capteurs'''
! scope=col | Modèle
! scope=col | Alimentation min/max
! scope=col | Prix
|-
| width="33%" |
<center>Température</center>
| width="34%" |
<center> TMP36GT9Z </center>
| width="33%" |
<center>2.7V/5.5V</center>
| width="33%" |
<center>1,46 €</center>
|-
| width="33%" |
<center>Accéléromètre</center>
| width="34%" |
<center> ADXL345BCCZ </center>
| width="33%" |
<center>2V/3.6V</center>
| width="33%" |
<center>5,54 €</center>
|-
| width="33%" |
<center>Gyroscope+Accéléromètre</center>
| width="34%" |
<center> MPU-6050</center>
| width="33%" |
<center>2.5V/3.6V</center>
| width="33%" |
<center>15,73 €</center>
|-
| width="33%" |
<center>Pression atmosphérique / Altitude</center>
| width="34%" |
<center> MPL3115A2 </center>
| width="33%" |
<center>1.95V/3.6V</center>
| width="33%" |
<center>2,65 €</center>
|}

* Pour minimiser les pertes on cherche a travailler avec une tension d'alimentation la plus faible possible. Je propose de travailler avec une tension d'alimentation de 3,3V (Validé à discuter à la réunion du Merdredi 07/10)

* Le système de récupération d'énergie fonctionnant sur la base d'un mouvement, j'ai choisi l'ensemble des capteur ci dessus qui me semble être adapté à l'intégration dans un système en mouvement. (Validé à discuter à la réunion du Merdredi 07/10)

* Récupération des modules RFduino, prise en main

===Semaine 3 (12/10/2015)===

* Installation des librairies

* Visualisation d'exemples

* Tests d'implantation du code source du projet P14: Aimant intelligent de la session IMA4: 2014/2015

* Optimisation du code pour la réduction de la consommation d'énergie

* Recherches sur d'autres composants dans l'optique d'une consommation toujours plus faible

{| class="wikitable centre" width="80%"
|+
|-
! scope=col | '''Capteurs'''
! scope=col | Modèle
! scope=col | Alimentation min/max
! scope=col | Prix
! scope=col | Consommation (typ/max)
|-
| width="33%" |
<center>Température</center>
| width="34%" |
<center> STLM20W87F </center>
| width="33%" |
<center>2.4V/5.5V</center>
| width="33%" |
<center> 0,775 € </center>
| width="33%" |
<center> 4.8 μA/8.0 μA </center>
|}

'''Calcul théorique de la consommation énergétique du module BLE + RFD22301'''

Mode "endormi" : ARM CPU Running Current + Output standard drive current = 4 + 0.5 = 4.5mA

Mode "acquisition": ARM CPU Running Current + Output high drive current = 5 + 4 = 9mA

Mode "transmission" : ARM CPU Running Current + Transmit Current + Output standard drive current = 4 + 0.5 + 12 = 16.5mA

http://www.rfduino.com/wp-content/uploads/2014/03/RFD22301.Data_.Sheet_.11.24.13_11.38PM.pdf

'''Code possible du mode "endormi"'''

pinMode(5, INPUT);
RFduino_pinWake(5, HIGH);

RFduino_ULPDelay(INFINITE);
if (RFduino_pinWoke(5))
{
state = ! state;
RFduinoGZLL.sendToHost(state);
}

http://forum.rfduino.com/index.php?topic=385.0

===Semaine 4 (19/10/2015)===

* Réunion du 21/10

* Réalisation de tests

* Ajustement du nombre de capteurs : dans un premier temps on utilisera le capteur de température puis l'accéléromètre

* Discussion sur le bac de test et méthodes de test : résistance de visualisation, chronométrage du temps de transmission, vitesse du processeur

* Réalisation des premiers relevés

===Semaine 5 (26/10/2015)===

* Recherche bibliographique sur les modes d'endormissement du module RFduino

* Essais de codes utilisant un mode d'endormissement plus profond

* Réalisation de graphique de l'énergie utilisée par le module lors de la transmission d'un message par le module BLE.

* Recherches sur des méthodes de programmation pour la diminution de la vitesse processeur

[[Fichier:P32Montage.jpg|250px|thumb|left|'''Montage de test''']]
[[Fichier:P32resultats.jpg|250px|thumb|center|'''Visualisation du courant consommé lors d'envoi toutes les 10ms''']]

* On visualise à l'oscilloscope des pic d'envoi et des pic d'avertissement de la balise BLE, on peut ainsi déduire la puissance nécessaire de chaque action

===Semaine 6 (02/11/2015)===

* Test de diminution de la vitesse processeur

* Réalisation de graphique démontrant l'impact de la réduction de la vitesse processeur sur l'énergie consommée et déduction d'une vitesse optimale pour notre application

* Réunion du 4/11

Définition d'objectifs : Création d'un fichier excel permettant de caractériser les coûts en énergies de chaque étapes de fonctionnement du système.

* Création d'un environnement de test "normé" ( Pour éviter les variations de mesures on réalise un banc et on applique les mêmes conditions de test pour chaque essai)

* Recherche bibliographique sur la norme BLE : recherche du temps maximum entre deux "avertissements" de la balise BLE

===Semaine 7 (09/11/2015)===
* Explication du principe de communication BLE pour l'exploitation des résultats

[[Fichier:Freq.PNG]]

Nous nous intéressons dans notre projet à "l'observateur". Cet objet peut avoir trois états : stand-by, advertising et en communication.

[[Fichier:Brod2.png]]

Dans le mode "Advertising" le système peut :

- Avertir le système récepteur de la proximité d'un capteur

- Avertir de la présence à un appareil souhaitant ce connecter

- Ce reconnecter de façon asynchrone

===Semaine 8 (16/11/2015)===

Analyse en détail d'une trame BLE

[[Fichier:Com.PNG]]

On constate que pendant la durée de la trame il y a un échange entre les deux objets appairé. On s’intéresse ici uniquement aux actions "Slave Tx". Le but étant d'identifier la durée et le courant consommé par ces actions pour obtenir des valeurs en joules.

[[Fichier:SchemaCom.PNG]]

On constate donc deux phases :

- Advertising event

- Connexion event

Nous allons essayer de retrouver et quantifié l'énergie consommé dans ces deux phases.

===Semaine 9 (23/11/2015)===

Lors de cette semaine nous avons effectué des tests en respectant une procédure de test précise. En effet les valeurs des courants que nous relevons sont très petites aussi chaque variation du montage est susceptible de perturber les valeurs.

[[Fichier:P32Conne.jpg|250px|thumb|left|'''Phase connexion''']]

[[Fichier:Avertissement.jpg|250px|thumb|center|'''Phase Advertising''']]

===Semaine 10 (30/11/2015)===

- On cherche a diminuer légèrement la consommation par des modifications logiciel :

Réduction de la puissance de la radio BLE : Diminution de la portée

Augmentation de la fréquence d'advertising : tant que la fréquence d'advetising est inférieure a cette de relevé des capteurs on s'assure que la donnée envoyée est toujours mise à jour.

[[Fichier:Pwl20-envoi.jpg|250px|thumb|left|'''Avec modification logiciel''']]

[[Fichier:Sans-pwlvl.jpg|250px|thumb|center|'''Sans modification logiciel''']]

- On concentre nos résultats dans un tableau récapitulatif en vue du dimensionnement de la batterie du système

[[Fichier:P32tbresul.PNG]]

===Semaine 11 (07/12/2015)===

Tests d'intégration de plusieurs capteur et observations des modification de la consommation des ADC et de la durée/consommation de la transmission.

Réunion de vérification des tests.

Mise en évidence de la dualité consommation d'énergie - Temps de réponse du système

En effet chaque "Advertisement" consomme une quantité d'énergie nous pouvons gérer l'espacement entre ceux-ci mais plus ce temps serra élevé plus il faudra de temps pour ce connecter à ce périphérique.

* Rédaction d'un rapport de test

* Rédaction du rapport de pré soutenance

===Semaine 12 (14/12/2015)===

* Recherches de solutions pour l'amélioration du modèle
* Recherches Matlab pour effectuer une analyse statistique d’avènements aléatoires sur la liaison

===Semaine 13 (04/01/2016)===

*Amélioration du modèle

L’amélioration du modèle est réalisée en tenant compte des facteurs influant sur la qualité de la transmission.

* Utilisation d'un picoscope : appareil permettant l’acquisition sur ordinateur de plusieurs formes d'ondes.
Ainsi grâce à un pico scope utilisé à l’IRCICA j’ai pu relever de nombreux échantillons nécessaires à une étude statistique des surcoûts en énergie.

[[Fichier:Montagemulti.jpg|250px|thumb|left|'''Montage multi récepteur''']]

===Semaine 14 (11/01/2016)===

* Compilation des résultats

* Exploitation Matlab

[[Fichier:Emistbrecap.PNG]]

===Semaine 15 (18/01/2016)===

Principe de fonctionnement du récupérateur d’énergie

Le récupérateur d’énergie fonctionne grâce à un patch piezo. Ce patch est capable de produire un courent à partir de la vélocité d’une impulsion suivent la formule :

[[Fichier:Equapiezo.PNG]]

[[Fichier:Modelepizo.PNG|250px|thumb|left|'''Modèle simplifié du patch piezo''']]

Pour récupérer de l’énergie il est couplé au système suivent :

[[Fichier:montagepiezo.PNG]]

La puissance du système est définie par :

P=V*im

L’énergie s’exprime alors :

[[Fichier:Equaenergie.PNG]]

L’énergie produite par le système est donc dépendante de la tension d’alimentation V de la constante électromécanique N et du choc produit sur le patch piezo.
Une impulsion sur le capteur piezo est de la forme :

La dérivée par rapport au temps de cette impulsion est donc de la forme :

Il est donc important de « fenêtrer » la tension pour ne récupérer que la partie positive.
Ce fenêtrage ainsi que la fréquence de commutation du hacheur est assurée par un microcontrôleur.

Dans la suite de notre étude nous ne tiendrons pas compte de la consommation de celui-ci.

===Semaine 16 (25/01/2016)===

* Réflexions sur le prototypage

* Présentation du récupérateur

* Mise en place du banc de test

* Premiers relevés

[[Fichier:Montagepiezo.jpg|250px|thumb|left|'''Montage piezo''']]
[[Fichier:Patchpiezo.jpg|250px|thumb|center|'''Patch piezo''']]

===Semaine 17 (01/02/2016)===

Test de la quantité d’énergie récupérée par un patch piezo

Méthodologie :

Channel rouge : Tension aux bornes du patch piezo. Ici on observe une fenêtre de tension de 4,5ms imposée par le microcontrôleur.

Channel vert : Tension aux bornes de la capacité C1 de 220nF
[[Fichier:Diffpot.png|250px|thumb|center|'''Tension patch piezo / Tension C1''']]

On constate qu’un choc sur le patch piezo produit une énergie suivent la formule, E = V * N * Δw
N étant une constante électromécanique, on va faire varier V pour évaluer le gain en énergie. Cependant Δw est généré par un choc d’un stylo sur le patch il n’est donc pas uniforme.
Nous utilisons donc une méthode statistique qui consiste à retirer deux extrémum et faire la moyenne de 10 mesures.

Nous obtenons la courbe suivante :

On constate que la courbe n’est pas linéaire comme l’aurai laissé supposer la formule. En effet jusqu’à 30V elle est linéaire croissante suivent l’équation :

Puis après 50V elle devient quadratique décroissante suivent la formule :

En effet la formule E = V * N * Δw néglige les pertes. Celles-ci deviennent plus importante a chaque augmentation de la tension d’alimentation.

On obtient donc un point de fonctionnement optimal a 30V pour notre système. Ce qui impose que notre système soit équipé d’une source de tension en conséquence.

===Semaine 18 (08/02/2016)===

*Réalisation de nombreux tests pour confirmation de la caractéristique

[[Fichier:P32Courbe.png]]

*Recherches de solution pour la réalisation d'un convertisseur buck pour passer de la tension récupérée ( ~ 50V ) au récupérateur d'énergie puis au module BLE ( 3.3 V )

*Solution 1 : http://www.ti.com/lit/ds/symlink/tps54060.pdf

*Solution 2: http://fr.farnell.com/stmicroelectronics/l78l33acz/regulateur-3-3v/dp/1467768

===Semaine 19 (15/02/2016)===

*Rédaction du rapport

===Semaine 20 (22/02/2016)===

== Annexes ==

Consommation du STM32L4 Series : http://www.st.com/web/en/catalog/mmc/FM141/SC1169/SS1580?sc=stm32l4

Réduction de la consommation de l'Arduino : http://www.home-automation-community.com/arduino-low-power-how-to-run-atmega328p-for-a-year-on-coin-cell-battery/

Consommation Raspberry : https://www.raspberrypi.org/help/faqs/

Module BLE : http://redbearlab.com/blemini/

Accéléromètre : http://fr.farnell.com/analog-devices/adxl345bccz/accelerometre-3-axes-14lga/dp/1853935

Capteur température : http://fr.farnell.com/analog-devices/tmp36gt9z/capteur-temp-to-92-3/dp/1438760?ost=TMP36GT9Z
ou http://fr.farnell.com/stmicroelectronics/stlm20w87f/capteur-de-temperature-analog/dp/1391131

Accéléromètre + Gyroscope : http://fr.farnell.com/invensense/mpu-6050/gyroscope-accelero-6-axes-i2c/dp/1864742

Altimètre : http://fr.farnell.com/freescale-semiconductor/mpl3115a2/pressure-sensor-20-110kpa-8lga/dp/2009084?ost=MPL3115A2&categoryId=700000004367

Explications norme BLE : chapters.comsoc.org/vancouver/BTLER3.pdf

http://www.argenox.com/bluetooth-low-energy-ble-v4-0-development/library/a-ble-advertising-primer/

----

Fichiers MATLAB

[[Fichier:Recuperation.zip]]

[[Fichier:Recuperation3.zip]]

== Rapport de Mi-projet ==

[[Fichier:CR_Miprojet_Sultana.pdf‎ ]]

P32 Récupération d'énergie pour balise BLE

2016-02-15T18:34:46Z

Qsultana : /* Semaine 19 (15/02/2016) */

== Objectif ==

Mon projet consiste à réaliser un système électronique autonome, composé de différents capteurs et capable de recueillir et de transmettre les données mémorisées vers un système centralisé.

== Etude préalable ==

L’énergie est le point de difficulté dans la réalisation de ce projet. Chaque élément devra être choisi non seulement pour ses performances mais également pour sa faible consommation.

== Organisation générale ==

Le système est organisé autour d’une source d’énergie, d’un contrôleur, de capteurs, de mémoire et d’un protocole de communication.

On cherche à minimiser l'énergie consommée par l'ensemble du système.

[[Fichier:P32Ensemble.PNG|250px|thumb|left|'''Architecture''']]

=== Chaine de l’énergie ===

L’énergie pour ce module autonome est constituée de quatre phases importantes :

[[Fichier:P32Energie.PNG]]

==== La récupération de l'énergie dans l'environnement ====

Il existe de nombreux moyens pour récupérer de l'énergie dans l'environnement. L'objectif est de trouver les sources les plus adaptées à l'environnement de l'application recherchée.

On peut citer:

* La récupération de l'énergie par différence de température

* Les panneaux photovoltaïques

* La récupération de l'énergie des ondes radio

* La Piézoélectricité

Dans ce projet nous utiliserons la piézoélectricité, le module de récupération ayant déjà fait partie d'une étude de IRCICA précédent le projet.

==== Le stockage de l’énergie ====

Le choix du système de stockage de l'énergie constitue une partie importante de la réalisation du système.
La problématique de cette partie sera de déterminer quel type de stockage nous utiliserons : batterie, super-capacité ou un hybride et de les dimensionner.
Il faudra tenir compte des problèmes de décharge partielle influent sur la durée de vie du stockage.

==== Le management/mise en forme de l’énergie ====

L'objectif de cette partie est d'étudier la nécessité de la mise en place d'une régulation tout en préservant des contraintes de consommation très faibles.

==== L'utilisation de l'énergie mise en forme ====

On cherche à minimiser l'énergie consommée par l'ensemble du système.

=== Contrôleur ===

Le microprocesseur : il existe différents types de microprocesseurs. L'objectif est de choisir un support capable de consommer un minimum d'énergie tout en conservant une taille minimale. Nous avons déjà utilisé dans d'autres projets des micro-contrôleurs de type Arduino et Raspberry pie. Ceux-ci ont pour avantage d’être prêts à l'emploi et faciles de prise en main. On peut s’orienter également vers un contrôleur ultra low power comme le STM32L4.

{| class="wikitable centre" width="80%"
|+
|-
! scope=col |
! scope=col | Consommation
! scope=col | Facilité de développement
! scope=col | Miniaturisation
|-
| width="33%" |
<center>Arduino</center>
| width="34%" |
<center>faible à très faible</center>
| width="33%" |
<center>bonne</center>
| width="33%" |
<center>faible</center>
|-
| width="33%" |
<center>Raspberry pi</center>
| width="34%" |
<center>importante</center>
| width="34%" |
<center>très bonne</center>
| width="34%" |
<center>très faible</center>
|-
| width="33%" |
<center>Ultra low power</center>
| width="34%" |
<center>très, très faible</center>
| width="33%" |
<center>difficile</center>
| width="33%" |
<center>forte</center>
|}

=== Capteurs ===

On peut imaginer différents types de capteurs :

* Accéléromètre

* Gyroscope

* Pression atmosphérique et altitude

* Température

* GPS

=== Mémoire ===

Le système doit être autonome et donc conserver un minimum de mesures pour les cas où la connexion est impossible. La mémoire doit être dimensionnée en fonction du nombre de capteurs, l’intervalle d’acquisition et le temps maximum avant connexion au système centralisé.

=== Protocole de communication ===

Un protocole de communication : dans un premier temps, nous nous concentrons sur le protocole BLE (Bluetooth Low Energie). Ce protocole étant standardisé, il nous permettra de recueillir de la documentation et réaliser des tests de consommation rapides.

== Planning prévisionnel ==

[[Fichier:P32Gant.PNG]]

==Suivi de l'avancement du Projet==
===Semaine 1 (28/09/2015)===

* Rencontre avec Monsieur Boe et Monsieur Giraud

* Présentation du projet

* Recherche documentaire

* Etablissement du cahier des charges

===Semaine 2 (05/10/2015)===

Recherche documentaire sur la consommation estimée des différents éléments.

{| class="wikitable centre" width="80%"
|+
|-
! scope=col | '''Contrôleur'''
! scope=col | Consommation Active
! scope=col | Consommation Inactive
! scope=col | Prix
|-
| width="33%" |
<center>Arduino Pro Mini 328 </center>
| width="34%" |
<center> 7mA (1 capteur)</center>
| width="33%" |
<center>4.5µA</center>
| width="33%" |
<center>Disponible</center>
|-
| width="33%" |
<center>STM32L4 Series (STM32L476JE)</center>
| width="34%" |
<center> 100 μA/MHz</center>
| width="33%" |
<center>120 nA</center>
| width="33%" |
<center>$5</center>
|-
| width="33%" |
<center>Raspberry</center>
| width="34%" |
<center> 200mA </center>
| width="33%" |
<center>200mA</center>
| width="33%" |
<center>Disponible</center>
|}

{| class="wikitable centre" width="80%"
|+
|-
! scope=col | '''Module BLE'''
! scope=col | Consommation
! scope=col | Options d'alimentation
! scope=col | Prix
|-
| width="33%" |
<center>BLE Mini</center>
| width="34%" |
<center> 15 mA </center>
| width="33%" |
<center>3.4V à 11V VIN / 5V USB / Coin Cell Battery (2025 or 2032) / 3.7V Li-ion Battery</center>
| width="33%" |
<center>$17</center>
|}

* <s> Le système Mini Arduino/ BLE Mini me semble être un bon compromis entre facilité d’intégration, consommation d'énergie et miniaturisation du système.</s> (Choix à discuter à la réunion du Merdredi 07/10)
* Choix du module RFduino

{| class="wikitable centre" width="80%"
|+
|-
! scope=col | '''Capteurs'''
! scope=col | Modèle
! scope=col | Alimentation min/max
! scope=col | Prix
|-
| width="33%" |
<center>Température</center>
| width="34%" |
<center> TMP36GT9Z </center>
| width="33%" |
<center>2.7V/5.5V</center>
| width="33%" |
<center>1,46 €</center>
|-
| width="33%" |
<center>Accéléromètre</center>
| width="34%" |
<center> ADXL345BCCZ </center>
| width="33%" |
<center>2V/3.6V</center>
| width="33%" |
<center>5,54 €</center>
|-
| width="33%" |
<center>Gyroscope+Accéléromètre</center>
| width="34%" |
<center> MPU-6050</center>
| width="33%" |
<center>2.5V/3.6V</center>
| width="33%" |
<center>15,73 €</center>
|-
| width="33%" |
<center>Pression atmosphérique / Altitude</center>
| width="34%" |
<center> MPL3115A2 </center>
| width="33%" |
<center>1.95V/3.6V</center>
| width="33%" |
<center>2,65 €</center>
|}

* Pour minimiser les pertes on cherche a travailler avec une tension d'alimentation la plus faible possible. Je propose de travailler avec une tension d'alimentation de 3,3V (Validé à discuter à la réunion du Merdredi 07/10)

* Le système de récupération d'énergie fonctionnant sur la base d'un mouvement, j'ai choisi l'ensemble des capteur ci dessus qui me semble être adapté à l'intégration dans un système en mouvement. (Validé à discuter à la réunion du Merdredi 07/10)

* Récupération des modules RFduino, prise en main

===Semaine 3 (12/10/2015)===

* Installation des librairies

* Visualisation d'exemples

* Tests d'implantation du code source du projet P14: Aimant intelligent de la session IMA4: 2014/2015

* Optimisation du code pour la réduction de la consommation d'énergie

* Recherches sur d'autres composants dans l'optique d'une consommation toujours plus faible

{| class="wikitable centre" width="80%"
|+
|-
! scope=col | '''Capteurs'''
! scope=col | Modèle
! scope=col | Alimentation min/max
! scope=col | Prix
! scope=col | Consommation (typ/max)
|-
| width="33%" |
<center>Température</center>
| width="34%" |
<center> STLM20W87F </center>
| width="33%" |
<center>2.4V/5.5V</center>
| width="33%" |
<center> 0,775 € </center>
| width="33%" |
<center> 4.8 μA/8.0 μA </center>
|}

'''Calcul théorique de la consommation énergétique du module BLE + RFD22301'''

Mode "endormi" : ARM CPU Running Current + Output standard drive current = 4 + 0.5 = 4.5mA

Mode "acquisition": ARM CPU Running Current + Output high drive current = 5 + 4 = 9mA

Mode "transmission" : ARM CPU Running Current + Transmit Current + Output standard drive current = 4 + 0.5 + 12 = 16.5mA

http://www.rfduino.com/wp-content/uploads/2014/03/RFD22301.Data_.Sheet_.11.24.13_11.38PM.pdf

'''Code possible du mode "endormi"'''

pinMode(5, INPUT);
RFduino_pinWake(5, HIGH);

RFduino_ULPDelay(INFINITE);
if (RFduino_pinWoke(5))
{
state = ! state;
RFduinoGZLL.sendToHost(state);
}

http://forum.rfduino.com/index.php?topic=385.0

===Semaine 4 (19/10/2015)===

* Réunion du 21/10

* Réalisation de tests

* Ajustement du nombre de capteurs : dans un premier temps on utilisera le capteur de température puis l'accéléromètre

* Discussion sur le bac de test et méthodes de test : résistance de visualisation, chronométrage du temps de transmission, vitesse du processeur

* Réalisation des premiers relevés

===Semaine 5 (26/10/2015)===

* Recherche bibliographique sur les modes d'endormissement du module RFduino

* Essais de codes utilisant un mode d'endormissement plus profond

* Réalisation de graphique de l'énergie utilisée par le module lors de la transmission d'un message par le module BLE.

* Recherches sur des méthodes de programmation pour la diminution de la vitesse processeur

[[Fichier:P32Montage.jpg|250px|thumb|left|'''Montage de test''']]
[[Fichier:P32resultats.jpg|250px|thumb|center|'''Visualisation du courant consommé lors d'envoi toutes les 10ms''']]

* On visualise à l'oscilloscope des pic d'envoi et des pic d'avertissement de la balise BLE, on peut ainsi déduire la puissance nécessaire de chaque action

===Semaine 6 (02/11/2015)===

* Test de diminution de la vitesse processeur

* Réalisation de graphique démontrant l'impact de la réduction de la vitesse processeur sur l'énergie consommée et déduction d'une vitesse optimale pour notre application

* Réunion du 4/11

Définition d'objectifs : Création d'un fichier excel permettant de caractériser les coûts en énergies de chaque étapes de fonctionnement du système.

* Création d'un environnement de test "normé" ( Pour éviter les variations de mesures on réalise un banc et on applique les mêmes conditions de test pour chaque essai)

* Recherche bibliographique sur la norme BLE : recherche du temps maximum entre deux "avertissements" de la balise BLE

===Semaine 7 (09/11/2015)===
* Explication du principe de communication BLE pour l'exploitation des résultats

[[Fichier:Freq.PNG]]

Nous nous intéressons dans notre projet à "l'observateur". Cet objet peut avoir trois états : stand-by, advertising et en communication.

[[Fichier:Brod2.png]]

Dans le mode "Advertising" le système peut :

- Avertir le système récepteur de la proximité d'un capteur

- Avertir de la présence à un appareil souhaitant ce connecter

- Ce reconnecter de façon asynchrone

===Semaine 8 (16/11/2015)===

Analyse en détail d'une trame BLE

[[Fichier:Com.PNG]]

On constate que pendant la durée de la trame il y a un échange entre les deux objets appairé. On s’intéresse ici uniquement aux actions "Slave Tx". Le but étant d'identifier la durée et le courant consommé par ces actions pour obtenir des valeurs en joules.

[[Fichier:SchemaCom.PNG]]

On constate donc deux phases :

- Advertising event

- Connexion event

Nous allons essayer de retrouver et quantifié l'énergie consommé dans ces deux phases.

===Semaine 9 (23/11/2015)===

Lors de cette semaine nous avons effectué des tests en respectant une procédure de test précise. En effet les valeurs des courants que nous relevons sont très petites aussi chaque variation du montage est susceptible de perturber les valeurs.

[[Fichier:P32Conne.jpg|250px|thumb|left|'''Phase connexion''']]

[[Fichier:Avertissement.jpg|250px|thumb|center|'''Phase Advertising''']]

===Semaine 10 (30/11/2015)===

- On cherche a diminuer légèrement la consommation par des modifications logiciel :

Réduction de la puissance de la radio BLE : Diminution de la portée

Augmentation de la fréquence d'advertising : tant que la fréquence d'advetising est inférieure a cette de relevé des capteurs on s'assure que la donnée envoyée est toujours mise à jour.

[[Fichier:Pwl20-envoi.jpg|250px|thumb|left|'''Avec modification logiciel''']]

[[Fichier:Sans-pwlvl.jpg|250px|thumb|center|'''Sans modification logiciel''']]

- On concentre nos résultats dans un tableau récapitulatif en vue du dimensionnement de la batterie du système

[[Fichier:P32tbresul.PNG]]

===Semaine 11 (07/12/2015)===

Tests d'intégration de plusieurs capteur et observations des modification de la consommation des ADC et de la durée/consommation de la transmission.

Réunion de vérification des tests.

Mise en évidence de la dualité consommation d'énergie - Temps de réponse du système

En effet chaque "Advertisement" consomme une quantité d'énergie nous pouvons gérer l'espacement entre ceux-ci mais plus ce temps serra élevé plus il faudra de temps pour ce connecter à ce périphérique.

* Rédaction d'un rapport de test

* Rédaction du rapport de pré soutenance

===Semaine 12 (14/12/2015)===

* Recherches de solutions pour l'amélioration du modèle
* Recherches Matlab pour effectuer une analyse statistique d’avènements aléatoires sur la liaison

===Semaine 13 (04/01/2016)===

*Amélioration du modèle

L’amélioration du modèle est réalisée en tenant compte des facteurs influent sur la qualité de la transmission.

* Utilisation d'un picoscope : appareil permettant l’acquisition sur ordinateur de plusieurs formes d'ondes.
Ainsi grâce a un pico scope utilisé à l’IRCICA j’ai pu relever de nombreux échantillons nécessaire a une étude statistique des surcoûts en énergie.

[[Fichier:Montagemulti.jpg|250px|thumb|left|'''Montage multi récepteur''']]

===Semaine 14 (11/01/2016)===

* Compilation des résultats

* Exploitation Matlab

[[Fichier:Emistbrecap.PNG]]

===Semaine 15 (18/01/2016)===

Principe de fonctionnement du récupérateur d’énergie

Le récupérateur d’énergie fonctionne grâce à un patch piezo. Ce patch est capable de produire un courent à partir de la vélocité d’une impulsion suivent la formule :

[[Fichier:Equapiezo.PNG]]

[[Fichier:Modelepizo.PNG|250px|thumb|left|'''Modèle simplifié du patch piezo''']]

Pour récupérer de l’énergie il est couplé au système suivent :

[[Fichier:montagepiezo.PNG]]

La puissance du système est définie par :

P=V*im

L’énergie s’exprime alors :

[[Fichier:Equaenergie.PNG]]

L’énergie produite par le système est donc dépendante de la tension d’alimentation V de la constante électromécanique N et du choc produit sur le patch piezo.
Une impulsion sur le capteur piezo est de la forme :

La dérivée par rapport au temps de cette impulsion est donc de la forme :

Il est donc important de « fenêtrer » la tension pour ne récupérer que la partie positive.
Ce fenêtrage ainsi que la fréquence de commutation du hacheur est assurée par un microcontrôleur.

Dans la suite de notre étude nous ne tiendrons pas compte de la consommation de celui-ci.

===Semaine 16 (25/01/2016)===

* Réflexions sur le prototypage

* Présentation du récupérateur

* Mise en place du banc de test

* Premiers relevés

[[Fichier:Montagepiezo.jpg|250px|thumb|left|'''Montage piezo''']]
[[Fichier:Patchpiezo.jpg|250px|thumb|center|'''Patch piezo''']]

===Semaine 17 (01/02/2016)===

Test de la quantité d’énergie récupérée par un patch piezo

Méthodologie :

Channel rouge : Tension aux bornes du patch piezo. Ici on observe une fenêtre de tension de 4,5ms imposée par le microcontrôleur.

Channel vert : Tension aux bornes de la capacité C1 de 220nF
[[Fichier:Diffpot.png|250px|thumb|center|'''Tension patch piezo / Tension C1''']]

On constate qu’un choc sur le patch piezo produit une énergie suivent la formule, E = V * N * Δw
N étant une constante électromécanique, on va faire varier V pour évaluer le gain en énergie. Cependant Δw est généré par un choc d’un stylo sur le patch il n’est donc pas uniforme.
Nous utilisons donc une méthode statistique qui consiste à retirer deux extrémum et faire la moyenne de 10 mesures.

Nous obtenons la courbe suivante :

On constate que la courbe n’est pas linéaire comme l’aurai laissé supposer la formule. En effet jusqu’à 30V elle est linéaire croissante suivent l’équation :

Puis après 50V elle devient quadratique décroissante suivent la formule :

En effet la formule E = V * N * Δw néglige les pertes. Celles-ci deviennent plus importante a chaque augmentation de la tension d’alimentation.

On obtient donc un point de fonctionnement optimal a 30V pour notre système. Ce qui impose que notre système soit équipé d’une source de tension en conséquence.

===Semaine 18 (08/02/2016)===

*Réalisation de nombreux tests pour confirmation de la caractéristique

[[Fichier:P32Courbe.png]]

*Recherches de solution pour la réalisation d'un convertisseur buck pour passer de la tension récupérée ( ~ 50V ) au récupérateur d'énergie puis au module BLE ( 3.3 V )

*Solution 1 : http://www.ti.com/lit/ds/symlink/tps54060.pdf

*Solution 2: http://fr.farnell.com/stmicroelectronics/l78l33acz/regulateur-3-3v/dp/1467768

===Semaine 19 (15/02/2016)===

*Rédaction du rapport

===Semaine 20 (22/02/2016)===

== Annexes ==

Consommation du STM32L4 Series : http://www.st.com/web/en/catalog/mmc/FM141/SC1169/SS1580?sc=stm32l4

Réduction de la consommation de l'Arduino : http://www.home-automation-community.com/arduino-low-power-how-to-run-atmega328p-for-a-year-on-coin-cell-battery/

Consommation Raspberry : https://www.raspberrypi.org/help/faqs/

Module BLE : http://redbearlab.com/blemini/

Accéléromètre : http://fr.farnell.com/analog-devices/adxl345bccz/accelerometre-3-axes-14lga/dp/1853935

Capteur température : http://fr.farnell.com/analog-devices/tmp36gt9z/capteur-temp-to-92-3/dp/1438760?ost=TMP36GT9Z
ou http://fr.farnell.com/stmicroelectronics/stlm20w87f/capteur-de-temperature-analog/dp/1391131

Accéléromètre + Gyroscope : http://fr.farnell.com/invensense/mpu-6050/gyroscope-accelero-6-axes-i2c/dp/1864742

Altimètre : http://fr.farnell.com/freescale-semiconductor/mpl3115a2/pressure-sensor-20-110kpa-8lga/dp/2009084?ost=MPL3115A2&categoryId=700000004367

Explications norme BLE : chapters.comsoc.org/vancouver/BTLER3.pdf

http://www.argenox.com/bluetooth-low-energy-ble-v4-0-development/library/a-ble-advertising-primer/

----

Fichiers MATLAB

[[Fichier:Recuperation.zip]]

[[Fichier:Recuperation3.zip]]

== Rapport de Mi-projet ==

[[Fichier:CR_Miprojet_Sultana.pdf‎ ]]

P32 Récupération d'énergie pour balise BLE

2016-02-15T18:34:18Z

Qsultana : /* Semaine 17 (01/02/2016) */

== Objectif ==

Mon projet consiste à réaliser un système électronique autonome, composé de différents capteurs et capable de recueillir et de transmettre les données mémorisées vers un système centralisé.

== Etude préalable ==

L’énergie est le point de difficulté dans la réalisation de ce projet. Chaque élément devra être choisi non seulement pour ses performances mais également pour sa faible consommation.

== Organisation générale ==

Le système est organisé autour d’une source d’énergie, d’un contrôleur, de capteurs, de mémoire et d’un protocole de communication.

On cherche à minimiser l'énergie consommée par l'ensemble du système.

[[Fichier:P32Ensemble.PNG|250px|thumb|left|'''Architecture''']]

=== Chaine de l’énergie ===

L’énergie pour ce module autonome est constituée de quatre phases importantes :

[[Fichier:P32Energie.PNG]]

==== La récupération de l'énergie dans l'environnement ====

Il existe de nombreux moyens pour récupérer de l'énergie dans l'environnement. L'objectif est de trouver les sources les plus adaptées à l'environnement de l'application recherchée.

On peut citer:

* La récupération de l'énergie par différence de température

* Les panneaux photovoltaïques

* La récupération de l'énergie des ondes radio

* La Piézoélectricité

Dans ce projet nous utiliserons la piézoélectricité, le module de récupération ayant déjà fait partie d'une étude de IRCICA précédent le projet.

==== Le stockage de l’énergie ====

Le choix du système de stockage de l'énergie constitue une partie importante de la réalisation du système.
La problématique de cette partie sera de déterminer quel type de stockage nous utiliserons : batterie, super-capacité ou un hybride et de les dimensionner.
Il faudra tenir compte des problèmes de décharge partielle influent sur la durée de vie du stockage.

==== Le management/mise en forme de l’énergie ====

L'objectif de cette partie est d'étudier la nécessité de la mise en place d'une régulation tout en préservant des contraintes de consommation très faibles.

==== L'utilisation de l'énergie mise en forme ====

On cherche à minimiser l'énergie consommée par l'ensemble du système.

=== Contrôleur ===

Le microprocesseur : il existe différents types de microprocesseurs. L'objectif est de choisir un support capable de consommer un minimum d'énergie tout en conservant une taille minimale. Nous avons déjà utilisé dans d'autres projets des micro-contrôleurs de type Arduino et Raspberry pie. Ceux-ci ont pour avantage d’être prêts à l'emploi et faciles de prise en main. On peut s’orienter également vers un contrôleur ultra low power comme le STM32L4.

{| class="wikitable centre" width="80%"
|+
|-
! scope=col |
! scope=col | Consommation
! scope=col | Facilité de développement
! scope=col | Miniaturisation
|-
| width="33%" |
<center>Arduino</center>
| width="34%" |
<center>faible à très faible</center>
| width="33%" |
<center>bonne</center>
| width="33%" |
<center>faible</center>
|-
| width="33%" |
<center>Raspberry pi</center>
| width="34%" |
<center>importante</center>
| width="34%" |
<center>très bonne</center>
| width="34%" |
<center>très faible</center>
|-
| width="33%" |
<center>Ultra low power</center>
| width="34%" |
<center>très, très faible</center>
| width="33%" |
<center>difficile</center>
| width="33%" |
<center>forte</center>
|}

=== Capteurs ===

On peut imaginer différents types de capteurs :

* Accéléromètre

* Gyroscope

* Pression atmosphérique et altitude

* Température

* GPS

=== Mémoire ===

Le système doit être autonome et donc conserver un minimum de mesures pour les cas où la connexion est impossible. La mémoire doit être dimensionnée en fonction du nombre de capteurs, l’intervalle d’acquisition et le temps maximum avant connexion au système centralisé.

=== Protocole de communication ===

Un protocole de communication : dans un premier temps, nous nous concentrons sur le protocole BLE (Bluetooth Low Energie). Ce protocole étant standardisé, il nous permettra de recueillir de la documentation et réaliser des tests de consommation rapides.

== Planning prévisionnel ==

[[Fichier:P32Gant.PNG]]

==Suivi de l'avancement du Projet==
===Semaine 1 (28/09/2015)===

* Rencontre avec Monsieur Boe et Monsieur Giraud

* Présentation du projet

* Recherche documentaire

* Etablissement du cahier des charges

===Semaine 2 (05/10/2015)===

Recherche documentaire sur la consommation estimée des différents éléments.

{| class="wikitable centre" width="80%"
|+
|-
! scope=col | '''Contrôleur'''
! scope=col | Consommation Active
! scope=col | Consommation Inactive
! scope=col | Prix
|-
| width="33%" |
<center>Arduino Pro Mini 328 </center>
| width="34%" |
<center> 7mA (1 capteur)</center>
| width="33%" |
<center>4.5µA</center>
| width="33%" |
<center>Disponible</center>
|-
| width="33%" |
<center>STM32L4 Series (STM32L476JE)</center>
| width="34%" |
<center> 100 μA/MHz</center>
| width="33%" |
<center>120 nA</center>
| width="33%" |
<center>$5</center>
|-
| width="33%" |
<center>Raspberry</center>
| width="34%" |
<center> 200mA </center>
| width="33%" |
<center>200mA</center>
| width="33%" |
<center>Disponible</center>
|}

{| class="wikitable centre" width="80%"
|+
|-
! scope=col | '''Module BLE'''
! scope=col | Consommation
! scope=col | Options d'alimentation
! scope=col | Prix
|-
| width="33%" |
<center>BLE Mini</center>
| width="34%" |
<center> 15 mA </center>
| width="33%" |
<center>3.4V à 11V VIN / 5V USB / Coin Cell Battery (2025 or 2032) / 3.7V Li-ion Battery</center>
| width="33%" |
<center>$17</center>
|}

* <s> Le système Mini Arduino/ BLE Mini me semble être un bon compromis entre facilité d’intégration, consommation d'énergie et miniaturisation du système.</s> (Choix à discuter à la réunion du Merdredi 07/10)
* Choix du module RFduino

{| class="wikitable centre" width="80%"
|+
|-
! scope=col | '''Capteurs'''
! scope=col | Modèle
! scope=col | Alimentation min/max
! scope=col | Prix
|-
| width="33%" |
<center>Température</center>
| width="34%" |
<center> TMP36GT9Z </center>
| width="33%" |
<center>2.7V/5.5V</center>
| width="33%" |
<center>1,46 €</center>
|-
| width="33%" |
<center>Accéléromètre</center>
| width="34%" |
<center> ADXL345BCCZ </center>
| width="33%" |
<center>2V/3.6V</center>
| width="33%" |
<center>5,54 €</center>
|-
| width="33%" |
<center>Gyroscope+Accéléromètre</center>
| width="34%" |
<center> MPU-6050</center>
| width="33%" |
<center>2.5V/3.6V</center>
| width="33%" |
<center>15,73 €</center>
|-
| width="33%" |
<center>Pression atmosphérique / Altitude</center>
| width="34%" |
<center> MPL3115A2 </center>
| width="33%" |
<center>1.95V/3.6V</center>
| width="33%" |
<center>2,65 €</center>
|}

* Pour minimiser les pertes on cherche a travailler avec une tension d'alimentation la plus faible possible. Je propose de travailler avec une tension d'alimentation de 3,3V (Validé à discuter à la réunion du Merdredi 07/10)

* Le système de récupération d'énergie fonctionnant sur la base d'un mouvement, j'ai choisi l'ensemble des capteur ci dessus qui me semble être adapté à l'intégration dans un système en mouvement. (Validé à discuter à la réunion du Merdredi 07/10)

* Récupération des modules RFduino, prise en main

===Semaine 3 (12/10/2015)===

* Installation des librairies

* Visualisation d'exemples

* Tests d'implantation du code source du projet P14: Aimant intelligent de la session IMA4: 2014/2015

* Optimisation du code pour la réduction de la consommation d'énergie

* Recherches sur d'autres composants dans l'optique d'une consommation toujours plus faible

{| class="wikitable centre" width="80%"
|+
|-
! scope=col | '''Capteurs'''
! scope=col | Modèle
! scope=col | Alimentation min/max
! scope=col | Prix
! scope=col | Consommation (typ/max)
|-
| width="33%" |
<center>Température</center>
| width="34%" |
<center> STLM20W87F </center>
| width="33%" |
<center>2.4V/5.5V</center>
| width="33%" |
<center> 0,775 € </center>
| width="33%" |
<center> 4.8 μA/8.0 μA </center>
|}

'''Calcul théorique de la consommation énergétique du module BLE + RFD22301'''

Mode "endormi" : ARM CPU Running Current + Output standard drive current = 4 + 0.5 = 4.5mA

Mode "acquisition": ARM CPU Running Current + Output high drive current = 5 + 4 = 9mA

Mode "transmission" : ARM CPU Running Current + Transmit Current + Output standard drive current = 4 + 0.5 + 12 = 16.5mA

http://www.rfduino.com/wp-content/uploads/2014/03/RFD22301.Data_.Sheet_.11.24.13_11.38PM.pdf

'''Code possible du mode "endormi"'''

pinMode(5, INPUT);
RFduino_pinWake(5, HIGH);

RFduino_ULPDelay(INFINITE);
if (RFduino_pinWoke(5))
{
state = ! state;
RFduinoGZLL.sendToHost(state);
}

http://forum.rfduino.com/index.php?topic=385.0

===Semaine 4 (19/10/2015)===

* Réunion du 21/10

* Réalisation de tests

* Ajustement du nombre de capteurs : dans un premier temps on utilisera le capteur de température puis l'accéléromètre

* Discussion sur le bac de test et méthodes de test : résistance de visualisation, chronométrage du temps de transmission, vitesse du processeur

* Réalisation des premiers relevés

===Semaine 5 (26/10/2015)===

* Recherche bibliographique sur les modes d'endormissement du module RFduino

* Essais de codes utilisant un mode d'endormissement plus profond

* Réalisation de graphique de l'énergie utilisée par le module lors de la transmission d'un message par le module BLE.

* Recherches sur des méthodes de programmation pour la diminution de la vitesse processeur

[[Fichier:P32Montage.jpg|250px|thumb|left|'''Montage de test''']]
[[Fichier:P32resultats.jpg|250px|thumb|center|'''Visualisation du courant consommé lors d'envoi toutes les 10ms''']]

* On visualise à l'oscilloscope des pic d'envoi et des pic d'avertissement de la balise BLE, on peut ainsi déduire la puissance nécessaire de chaque action

===Semaine 6 (02/11/2015)===

* Test de diminution de la vitesse processeur

* Réalisation de graphique démontrant l'impact de la réduction de la vitesse processeur sur l'énergie consommée et déduction d'une vitesse optimale pour notre application

* Réunion du 4/11

Définition d'objectifs : Création d'un fichier excel permettant de caractériser les coûts en énergies de chaque étapes de fonctionnement du système.

* Création d'un environnement de test "normé" ( Pour éviter les variations de mesures on réalise un banc et on applique les mêmes conditions de test pour chaque essai)

* Recherche bibliographique sur la norme BLE : recherche du temps maximum entre deux "avertissements" de la balise BLE

===Semaine 7 (09/11/2015)===
* Explication du principe de communication BLE pour l'exploitation des résultats

[[Fichier:Freq.PNG]]

Nous nous intéressons dans notre projet à "l'observateur". Cet objet peut avoir trois états : stand-by, advertising et en communication.

[[Fichier:Brod2.png]]

Dans le mode "Advertising" le système peut :

- Avertir le système récepteur de la proximité d'un capteur

- Avertir de la présence à un appareil souhaitant ce connecter

- Ce reconnecter de façon asynchrone

===Semaine 8 (16/11/2015)===

Analyse en détail d'une trame BLE

[[Fichier:Com.PNG]]

On constate que pendant la durée de la trame il y a un échange entre les deux objets appairé. On s’intéresse ici uniquement aux actions "Slave Tx". Le but étant d'identifier la durée et le courant consommé par ces actions pour obtenir des valeurs en joules.

[[Fichier:SchemaCom.PNG]]

On constate donc deux phases :

- Advertising event

- Connexion event

Nous allons essayer de retrouver et quantifié l'énergie consommé dans ces deux phases.

===Semaine 9 (23/11/2015)===

Lors de cette semaine nous avons effectué des tests en respectant une procédure de test précise. En effet les valeurs des courants que nous relevons sont très petites aussi chaque variation du montage est susceptible de perturber les valeurs.

[[Fichier:P32Conne.jpg|250px|thumb|left|'''Phase connexion''']]

[[Fichier:Avertissement.jpg|250px|thumb|center|'''Phase Advertising''']]

===Semaine 10 (30/11/2015)===

- On cherche a diminuer légèrement la consommation par des modifications logiciel :

Réduction de la puissance de la radio BLE : Diminution de la portée

Augmentation de la fréquence d'advertising : tant que la fréquence d'advetising est inférieure a cette de relevé des capteurs on s'assure que la donnée envoyée est toujours mise à jour.

[[Fichier:Pwl20-envoi.jpg|250px|thumb|left|'''Avec modification logiciel''']]

[[Fichier:Sans-pwlvl.jpg|250px|thumb|center|'''Sans modification logiciel''']]

- On concentre nos résultats dans un tableau récapitulatif en vue du dimensionnement de la batterie du système

[[Fichier:P32tbresul.PNG]]

===Semaine 11 (07/12/2015)===

Tests d'intégration de plusieurs capteur et observations des modification de la consommation des ADC et de la durée/consommation de la transmission.

Réunion de vérification des tests.

Mise en évidence de la dualité consommation d'énergie - Temps de réponse du système

En effet chaque "Advertisement" consomme une quantité d'énergie nous pouvons gérer l'espacement entre ceux-ci mais plus ce temps serra élevé plus il faudra de temps pour ce connecter à ce périphérique.

* Rédaction d'un rapport de test

* Rédaction du rapport de pré soutenance

===Semaine 12 (14/12/2015)===

* Recherches de solutions pour l'amélioration du modèle
* Recherches Matlab pour effectuer une analyse statistique d’avènements aléatoires sur la liaison

===Semaine 13 (04/01/2016)===

*Amélioration du modèle

L’amélioration du modèle est réalisée en tenant compte des facteurs influent sur la qualité de la transmission.

* Utilisation d'un picoscope : appareil permettant l’acquisition sur ordinateur de plusieurs formes d'ondes.
Ainsi grâce a un pico scope utilisé à l’IRCICA j’ai pu relever de nombreux échantillons nécessaire a une étude statistique des surcoûts en énergie.

[[Fichier:Montagemulti.jpg|250px|thumb|left|'''Montage multi récepteur''']]

===Semaine 14 (11/01/2016)===

* Compilation des résultats

* Exploitation Matlab

[[Fichier:Emistbrecap.PNG]]

===Semaine 15 (18/01/2016)===

Principe de fonctionnement du récupérateur d’énergie

Le récupérateur d’énergie fonctionne grâce à un patch piezo. Ce patch est capable de produire un courent à partir de la vélocité d’une impulsion suivent la formule :

[[Fichier:Equapiezo.PNG]]

[[Fichier:Modelepizo.PNG|250px|thumb|left|'''Modèle simplifié du patch piezo''']]

Pour récupérer de l’énergie il est couplé au système suivent :

[[Fichier:montagepiezo.PNG]]

La puissance du système est définie par :

P=V*im

L’énergie s’exprime alors :

[[Fichier:Equaenergie.PNG]]

L’énergie produite par le système est donc dépendante de la tension d’alimentation V de la constante électromécanique N et du choc produit sur le patch piezo.
Une impulsion sur le capteur piezo est de la forme :

La dérivée par rapport au temps de cette impulsion est donc de la forme :

Il est donc important de « fenêtrer » la tension pour ne récupérer que la partie positive.
Ce fenêtrage ainsi que la fréquence de commutation du hacheur est assurée par un microcontrôleur.

Dans la suite de notre étude nous ne tiendrons pas compte de la consommation de celui-ci.

===Semaine 16 (25/01/2016)===

* Réflexions sur le prototypage

* Présentation du récupérateur

* Mise en place du banc de test

* Premiers relevés

[[Fichier:Montagepiezo.jpg|250px|thumb|left|'''Montage piezo''']]
[[Fichier:Patchpiezo.jpg|250px|thumb|center|'''Patch piezo''']]

===Semaine 17 (01/02/2016)===

Test de la quantité d’énergie récupérée par un patch piezo

Méthodologie :

Channel rouge : Tension aux bornes du patch piezo. Ici on observe une fenêtre de tension de 4,5ms imposée par le microcontrôleur.

Channel vert : Tension aux bornes de la capacité C1 de 220nF
[[Fichier:Diffpot.png|250px|thumb|center|'''Tension patch piezo / Tension C1''']]

On constate qu’un choc sur le patch piezo produit une énergie suivent la formule, E = V * N * Δw
N étant une constante électromécanique, on va faire varier V pour évaluer le gain en énergie. Cependant Δw est généré par un choc d’un stylo sur le patch il n’est donc pas uniforme.
Nous utilisons donc une méthode statistique qui consiste à retirer deux extrémum et faire la moyenne de 10 mesures.

Nous obtenons la courbe suivante :

On constate que la courbe n’est pas linéaire comme l’aurai laissé supposer la formule. En effet jusqu’à 30V elle est linéaire croissante suivent l’équation :

Puis après 50V elle devient quadratique décroissante suivent la formule :

En effet la formule E = V * N * Δw néglige les pertes. Celles-ci deviennent plus importante a chaque augmentation de la tension d’alimentation.

On obtient donc un point de fonctionnement optimal a 30V pour notre système. Ce qui impose que notre système soit équipé d’une source de tension en conséquence.

===Semaine 18 (08/02/2016)===

*Réalisation de nombreux tests pour confirmation de la caractéristique

[[Fichier:P32Courbe.png]]

*Recherches de solution pour la réalisation d'un convertisseur buck pour passer de la tension récupérée ( ~ 50V ) au récupérateur d'énergie puis au module BLE ( 3.3 V )

*Solution 1 : http://www.ti.com/lit/ds/symlink/tps54060.pdf

*Solution 2: http://fr.farnell.com/stmicroelectronics/l78l33acz/regulateur-3-3v/dp/1467768

===Semaine 19 (15/02/2016)===
===Semaine 20 (22/02/2016)===

== Annexes ==

Consommation du STM32L4 Series : http://www.st.com/web/en/catalog/mmc/FM141/SC1169/SS1580?sc=stm32l4

Réduction de la consommation de l'Arduino : http://www.home-automation-community.com/arduino-low-power-how-to-run-atmega328p-for-a-year-on-coin-cell-battery/

Consommation Raspberry : https://www.raspberrypi.org/help/faqs/

Module BLE : http://redbearlab.com/blemini/

Accéléromètre : http://fr.farnell.com/analog-devices/adxl345bccz/accelerometre-3-axes-14lga/dp/1853935

Capteur température : http://fr.farnell.com/analog-devices/tmp36gt9z/capteur-temp-to-92-3/dp/1438760?ost=TMP36GT9Z
ou http://fr.farnell.com/stmicroelectronics/stlm20w87f/capteur-de-temperature-analog/dp/1391131

Accéléromètre + Gyroscope : http://fr.farnell.com/invensense/mpu-6050/gyroscope-accelero-6-axes-i2c/dp/1864742

Altimètre : http://fr.farnell.com/freescale-semiconductor/mpl3115a2/pressure-sensor-20-110kpa-8lga/dp/2009084?ost=MPL3115A2&categoryId=700000004367

Explications norme BLE : chapters.comsoc.org/vancouver/BTLER3.pdf

http://www.argenox.com/bluetooth-low-energy-ble-v4-0-development/library/a-ble-advertising-primer/

----

Fichiers MATLAB

[[Fichier:Recuperation.zip]]

[[Fichier:Recuperation3.zip]]

== Rapport de Mi-projet ==

[[Fichier:CR_Miprojet_Sultana.pdf‎ ]]

P32 Récupération d'énergie pour balise BLE

2016-02-15T18:34:03Z

Qsultana : /* Semaine 18 (08/02/2016) */

== Objectif ==

Mon projet consiste à réaliser un système électronique autonome, composé de différents capteurs et capable de recueillir et de transmettre les données mémorisées vers un système centralisé.

== Etude préalable ==

L’énergie est le point de difficulté dans la réalisation de ce projet. Chaque élément devra être choisi non seulement pour ses performances mais également pour sa faible consommation.

== Organisation générale ==

Le système est organisé autour d’une source d’énergie, d’un contrôleur, de capteurs, de mémoire et d’un protocole de communication.

On cherche à minimiser l'énergie consommée par l'ensemble du système.

[[Fichier:P32Ensemble.PNG|250px|thumb|left|'''Architecture''']]

=== Chaine de l’énergie ===

L’énergie pour ce module autonome est constituée de quatre phases importantes :

[[Fichier:P32Energie.PNG]]

==== La récupération de l'énergie dans l'environnement ====

Il existe de nombreux moyens pour récupérer de l'énergie dans l'environnement. L'objectif est de trouver les sources les plus adaptées à l'environnement de l'application recherchée.

On peut citer:

* La récupération de l'énergie par différence de température

* Les panneaux photovoltaïques

* La récupération de l'énergie des ondes radio

* La Piézoélectricité

Dans ce projet nous utiliserons la piézoélectricité, le module de récupération ayant déjà fait partie d'une étude de IRCICA précédent le projet.

==== Le stockage de l’énergie ====

Le choix du système de stockage de l'énergie constitue une partie importante de la réalisation du système.
La problématique de cette partie sera de déterminer quel type de stockage nous utiliserons : batterie, super-capacité ou un hybride et de les dimensionner.
Il faudra tenir compte des problèmes de décharge partielle influent sur la durée de vie du stockage.

==== Le management/mise en forme de l’énergie ====

L'objectif de cette partie est d'étudier la nécessité de la mise en place d'une régulation tout en préservant des contraintes de consommation très faibles.

==== L'utilisation de l'énergie mise en forme ====

On cherche à minimiser l'énergie consommée par l'ensemble du système.

=== Contrôleur ===

Le microprocesseur : il existe différents types de microprocesseurs. L'objectif est de choisir un support capable de consommer un minimum d'énergie tout en conservant une taille minimale. Nous avons déjà utilisé dans d'autres projets des micro-contrôleurs de type Arduino et Raspberry pie. Ceux-ci ont pour avantage d’être prêts à l'emploi et faciles de prise en main. On peut s’orienter également vers un contrôleur ultra low power comme le STM32L4.

{| class="wikitable centre" width="80%"
|+
|-
! scope=col |
! scope=col | Consommation
! scope=col | Facilité de développement
! scope=col | Miniaturisation
|-
| width="33%" |
<center>Arduino</center>
| width="34%" |
<center>faible à très faible</center>
| width="33%" |
<center>bonne</center>
| width="33%" |
<center>faible</center>
|-
| width="33%" |
<center>Raspberry pi</center>
| width="34%" |
<center>importante</center>
| width="34%" |
<center>très bonne</center>
| width="34%" |
<center>très faible</center>
|-
| width="33%" |
<center>Ultra low power</center>
| width="34%" |
<center>très, très faible</center>
| width="33%" |
<center>difficile</center>
| width="33%" |
<center>forte</center>
|}

=== Capteurs ===

On peut imaginer différents types de capteurs :

* Accéléromètre

* Gyroscope

* Pression atmosphérique et altitude

* Température

* GPS

=== Mémoire ===

Le système doit être autonome et donc conserver un minimum de mesures pour les cas où la connexion est impossible. La mémoire doit être dimensionnée en fonction du nombre de capteurs, l’intervalle d’acquisition et le temps maximum avant connexion au système centralisé.

=== Protocole de communication ===

Un protocole de communication : dans un premier temps, nous nous concentrons sur le protocole BLE (Bluetooth Low Energie). Ce protocole étant standardisé, il nous permettra de recueillir de la documentation et réaliser des tests de consommation rapides.

== Planning prévisionnel ==

[[Fichier:P32Gant.PNG]]

==Suivi de l'avancement du Projet==
===Semaine 1 (28/09/2015)===

* Rencontre avec Monsieur Boe et Monsieur Giraud

* Présentation du projet

* Recherche documentaire

* Etablissement du cahier des charges

===Semaine 2 (05/10/2015)===

Recherche documentaire sur la consommation estimée des différents éléments.

{| class="wikitable centre" width="80%"
|+
|-
! scope=col | '''Contrôleur'''
! scope=col | Consommation Active
! scope=col | Consommation Inactive
! scope=col | Prix
|-
| width="33%" |
<center>Arduino Pro Mini 328 </center>
| width="34%" |
<center> 7mA (1 capteur)</center>
| width="33%" |
<center>4.5µA</center>
| width="33%" |
<center>Disponible</center>
|-
| width="33%" |
<center>STM32L4 Series (STM32L476JE)</center>
| width="34%" |
<center> 100 μA/MHz</center>
| width="33%" |
<center>120 nA</center>
| width="33%" |
<center>$5</center>
|-
| width="33%" |
<center>Raspberry</center>
| width="34%" |
<center> 200mA </center>
| width="33%" |
<center>200mA</center>
| width="33%" |
<center>Disponible</center>
|}

{| class="wikitable centre" width="80%"
|+
|-
! scope=col | '''Module BLE'''
! scope=col | Consommation
! scope=col | Options d'alimentation
! scope=col | Prix
|-
| width="33%" |
<center>BLE Mini</center>
| width="34%" |
<center> 15 mA </center>
| width="33%" |
<center>3.4V à 11V VIN / 5V USB / Coin Cell Battery (2025 or 2032) / 3.7V Li-ion Battery</center>
| width="33%" |
<center>$17</center>
|}

* <s> Le système Mini Arduino/ BLE Mini me semble être un bon compromis entre facilité d’intégration, consommation d'énergie et miniaturisation du système.</s> (Choix à discuter à la réunion du Merdredi 07/10)
* Choix du module RFduino

{| class="wikitable centre" width="80%"
|+
|-
! scope=col | '''Capteurs'''
! scope=col | Modèle
! scope=col | Alimentation min/max
! scope=col | Prix
|-
| width="33%" |
<center>Température</center>
| width="34%" |
<center> TMP36GT9Z </center>
| width="33%" |
<center>2.7V/5.5V</center>
| width="33%" |
<center>1,46 €</center>
|-
| width="33%" |
<center>Accéléromètre</center>
| width="34%" |
<center> ADXL345BCCZ </center>
| width="33%" |
<center>2V/3.6V</center>
| width="33%" |
<center>5,54 €</center>
|-
| width="33%" |
<center>Gyroscope+Accéléromètre</center>
| width="34%" |
<center> MPU-6050</center>
| width="33%" |
<center>2.5V/3.6V</center>
| width="33%" |
<center>15,73 €</center>
|-
| width="33%" |
<center>Pression atmosphérique / Altitude</center>
| width="34%" |
<center> MPL3115A2 </center>
| width="33%" |
<center>1.95V/3.6V</center>
| width="33%" |
<center>2,65 €</center>
|}

* Pour minimiser les pertes on cherche a travailler avec une tension d'alimentation la plus faible possible. Je propose de travailler avec une tension d'alimentation de 3,3V (Validé à discuter à la réunion du Merdredi 07/10)

* Le système de récupération d'énergie fonctionnant sur la base d'un mouvement, j'ai choisi l'ensemble des capteur ci dessus qui me semble être adapté à l'intégration dans un système en mouvement. (Validé à discuter à la réunion du Merdredi 07/10)

* Récupération des modules RFduino, prise en main

===Semaine 3 (12/10/2015)===

* Installation des librairies

* Visualisation d'exemples

* Tests d'implantation du code source du projet P14: Aimant intelligent de la session IMA4: 2014/2015

* Optimisation du code pour la réduction de la consommation d'énergie

* Recherches sur d'autres composants dans l'optique d'une consommation toujours plus faible

{| class="wikitable centre" width="80%"
|+
|-
! scope=col | '''Capteurs'''
! scope=col | Modèle
! scope=col | Alimentation min/max
! scope=col | Prix
! scope=col | Consommation (typ/max)
|-
| width="33%" |
<center>Température</center>
| width="34%" |
<center> STLM20W87F </center>
| width="33%" |
<center>2.4V/5.5V</center>
| width="33%" |
<center> 0,775 € </center>
| width="33%" |
<center> 4.8 μA/8.0 μA </center>
|}

'''Calcul théorique de la consommation énergétique du module BLE + RFD22301'''

Mode "endormi" : ARM CPU Running Current + Output standard drive current = 4 + 0.5 = 4.5mA

Mode "acquisition": ARM CPU Running Current + Output high drive current = 5 + 4 = 9mA

Mode "transmission" : ARM CPU Running Current + Transmit Current + Output standard drive current = 4 + 0.5 + 12 = 16.5mA

http://www.rfduino.com/wp-content/uploads/2014/03/RFD22301.Data_.Sheet_.11.24.13_11.38PM.pdf

'''Code possible du mode "endormi"'''

pinMode(5, INPUT);
RFduino_pinWake(5, HIGH);

RFduino_ULPDelay(INFINITE);
if (RFduino_pinWoke(5))
{
state = ! state;
RFduinoGZLL.sendToHost(state);
}

http://forum.rfduino.com/index.php?topic=385.0

===Semaine 4 (19/10/2015)===

* Réunion du 21/10

* Réalisation de tests

* Ajustement du nombre de capteurs : dans un premier temps on utilisera le capteur de température puis l'accéléromètre

* Discussion sur le bac de test et méthodes de test : résistance de visualisation, chronométrage du temps de transmission, vitesse du processeur

* Réalisation des premiers relevés

===Semaine 5 (26/10/2015)===

* Recherche bibliographique sur les modes d'endormissement du module RFduino

* Essais de codes utilisant un mode d'endormissement plus profond

* Réalisation de graphique de l'énergie utilisée par le module lors de la transmission d'un message par le module BLE.

* Recherches sur des méthodes de programmation pour la diminution de la vitesse processeur

[[Fichier:P32Montage.jpg|250px|thumb|left|'''Montage de test''']]
[[Fichier:P32resultats.jpg|250px|thumb|center|'''Visualisation du courant consommé lors d'envoi toutes les 10ms''']]

* On visualise à l'oscilloscope des pic d'envoi et des pic d'avertissement de la balise BLE, on peut ainsi déduire la puissance nécessaire de chaque action

===Semaine 6 (02/11/2015)===

* Test de diminution de la vitesse processeur

* Réalisation de graphique démontrant l'impact de la réduction de la vitesse processeur sur l'énergie consommée et déduction d'une vitesse optimale pour notre application

* Réunion du 4/11

Définition d'objectifs : Création d'un fichier excel permettant de caractériser les coûts en énergies de chaque étapes de fonctionnement du système.

* Création d'un environnement de test "normé" ( Pour éviter les variations de mesures on réalise un banc et on applique les mêmes conditions de test pour chaque essai)

* Recherche bibliographique sur la norme BLE : recherche du temps maximum entre deux "avertissements" de la balise BLE

===Semaine 7 (09/11/2015)===
* Explication du principe de communication BLE pour l'exploitation des résultats

[[Fichier:Freq.PNG]]

Nous nous intéressons dans notre projet à "l'observateur". Cet objet peut avoir trois états : stand-by, advertising et en communication.

[[Fichier:Brod2.png]]

Dans le mode "Advertising" le système peut :

- Avertir le système récepteur de la proximité d'un capteur

- Avertir de la présence à un appareil souhaitant ce connecter

- Ce reconnecter de façon asynchrone

===Semaine 8 (16/11/2015)===

Analyse en détail d'une trame BLE

[[Fichier:Com.PNG]]

On constate que pendant la durée de la trame il y a un échange entre les deux objets appairé. On s’intéresse ici uniquement aux actions "Slave Tx". Le but étant d'identifier la durée et le courant consommé par ces actions pour obtenir des valeurs en joules.

[[Fichier:SchemaCom.PNG]]

On constate donc deux phases :

- Advertising event

- Connexion event

Nous allons essayer de retrouver et quantifié l'énergie consommé dans ces deux phases.

===Semaine 9 (23/11/2015)===

Lors de cette semaine nous avons effectué des tests en respectant une procédure de test précise. En effet les valeurs des courants que nous relevons sont très petites aussi chaque variation du montage est susceptible de perturber les valeurs.

[[Fichier:P32Conne.jpg|250px|thumb|left|'''Phase connexion''']]

[[Fichier:Avertissement.jpg|250px|thumb|center|'''Phase Advertising''']]

===Semaine 10 (30/11/2015)===

- On cherche a diminuer légèrement la consommation par des modifications logiciel :

Réduction de la puissance de la radio BLE : Diminution de la portée

Augmentation de la fréquence d'advertising : tant que la fréquence d'advetising est inférieure a cette de relevé des capteurs on s'assure que la donnée envoyée est toujours mise à jour.

[[Fichier:Pwl20-envoi.jpg|250px|thumb|left|'''Avec modification logiciel''']]

[[Fichier:Sans-pwlvl.jpg|250px|thumb|center|'''Sans modification logiciel''']]

- On concentre nos résultats dans un tableau récapitulatif en vue du dimensionnement de la batterie du système

[[Fichier:P32tbresul.PNG]]

===Semaine 11 (07/12/2015)===

Tests d'intégration de plusieurs capteur et observations des modification de la consommation des ADC et de la durée/consommation de la transmission.

Réunion de vérification des tests.

Mise en évidence de la dualité consommation d'énergie - Temps de réponse du système

En effet chaque "Advertisement" consomme une quantité d'énergie nous pouvons gérer l'espacement entre ceux-ci mais plus ce temps serra élevé plus il faudra de temps pour ce connecter à ce périphérique.

* Rédaction d'un rapport de test

* Rédaction du rapport de pré soutenance

===Semaine 12 (14/12/2015)===

* Recherches de solutions pour l'amélioration du modèle
* Recherches Matlab pour effectuer une analyse statistique d’avènements aléatoires sur la liaison

===Semaine 13 (04/01/2016)===

*Amélioration du modèle

L’amélioration du modèle est réalisée en tenant compte des facteurs influent sur la qualité de la transmission.

* Utilisation d'un picoscope : appareil permettant l’acquisition sur ordinateur de plusieurs formes d'ondes.
Ainsi grâce a un pico scope utilisé à l’IRCICA j’ai pu relever de nombreux échantillons nécessaire a une étude statistique des surcoûts en énergie.

[[Fichier:Montagemulti.jpg|250px|thumb|left|'''Montage multi récepteur''']]

===Semaine 14 (11/01/2016)===

* Compilation des résultats

* Exploitation Matlab

[[Fichier:Emistbrecap.PNG]]

===Semaine 15 (18/01/2016)===

Principe de fonctionnement du récupérateur d’énergie

Le récupérateur d’énergie fonctionne grâce à un patch piezo. Ce patch est capable de produire un courent à partir de la vélocité d’une impulsion suivent la formule :

[[Fichier:Equapiezo.PNG]]

[[Fichier:Modelepizo.PNG|250px|thumb|left|'''Modèle simplifié du patch piezo''']]

Pour récupérer de l’énergie il est couplé au système suivent :

[[Fichier:montagepiezo.PNG]]

La puissance du système est définie par :

P=V*im

L’énergie s’exprime alors :

[[Fichier:Equaenergie.PNG]]

L’énergie produite par le système est donc dépendante de la tension d’alimentation V de la constante électromécanique N et du choc produit sur le patch piezo.
Une impulsion sur le capteur piezo est de la forme :

La dérivée par rapport au temps de cette impulsion est donc de la forme :

Il est donc important de « fenêtrer » la tension pour ne récupérer que la partie positive.
Ce fenêtrage ainsi que la fréquence de commutation du hacheur est assurée par un microcontrôleur.

Dans la suite de notre étude nous ne tiendrons pas compte de la consommation de celui-ci.

===Semaine 16 (25/01/2016)===

* Réflexions sur le prototypage

* Présentation du récupérateur

* Mise en place du banc de test

* Premiers relevés

[[Fichier:Montagepiezo.jpg|250px|thumb|left|'''Montage piezo''']]
[[Fichier:Patchpiezo.jpg|250px|thumb|center|'''Patch piezo''']]

===Semaine 17 (01/02/2016)===

Test de la quantité d’énergie récupérée par un patch piezo

Méthodologie :

Channel rouge : Tension aux bornes du patch piezo. Ici on observe une fenêtre de tension de 4,5ms imposée par le microcontrôleur.

Channel vert : Tension aux bornes de la capacité C1 de 220nF
[[Fichier:Diffpot.png|250px|thumb|center|'''Tension patch piezo / Tension C1''']]

On constate qu’un choc sur le patch piezo produit une énergie suivent la formule, E = V * N * Δw
N étant une constante électromécanique, on va faire varier V pour évaluer le gain en énergie. Cependant Δw est généré par un choc d’un stylo sur le patch il n’est donc pas uniforme.
Nous utilisons donc une méthode statistique qui consiste à retirer deux extrémum et faire la moyenne de 10 mesures.

Nous obtenons la courbe suivante :

On constate que la courbe n’est pas linéaire comme l’aurai laissé supposer la formule. En effet jusqu’à 30V elle est linéaire croissante suivent l’équation :

Puis après 30V elle devient quadratique décroissante suivent la formule :

En effet la formule E = V * N * Δw néglige les pertes. Celles-ci deviennent plus importante a chaque augmentation de la tension d’alimentation.

On obtient donc un point de fonctionnement optimal a 30V pour notre système. Ce qui impose que notre système soit équipé d’une source de tension en conséquence.

===Semaine 18 (08/02/2016)===

*Réalisation de nombreux tests pour confirmation de la caractéristique

[[Fichier:P32Courbe.png]]

*Recherches de solution pour la réalisation d'un convertisseur buck pour passer de la tension récupérée ( ~ 50V ) au récupérateur d'énergie puis au module BLE ( 3.3 V )

*Solution 1 : http://www.ti.com/lit/ds/symlink/tps54060.pdf

*Solution 2: http://fr.farnell.com/stmicroelectronics/l78l33acz/regulateur-3-3v/dp/1467768

===Semaine 19 (15/02/2016)===
===Semaine 20 (22/02/2016)===

== Annexes ==

Consommation du STM32L4 Series : http://www.st.com/web/en/catalog/mmc/FM141/SC1169/SS1580?sc=stm32l4

Réduction de la consommation de l'Arduino : http://www.home-automation-community.com/arduino-low-power-how-to-run-atmega328p-for-a-year-on-coin-cell-battery/

Consommation Raspberry : https://www.raspberrypi.org/help/faqs/

Module BLE : http://redbearlab.com/blemini/

Accéléromètre : http://fr.farnell.com/analog-devices/adxl345bccz/accelerometre-3-axes-14lga/dp/1853935

Capteur température : http://fr.farnell.com/analog-devices/tmp36gt9z/capteur-temp-to-92-3/dp/1438760?ost=TMP36GT9Z
ou http://fr.farnell.com/stmicroelectronics/stlm20w87f/capteur-de-temperature-analog/dp/1391131

Accéléromètre + Gyroscope : http://fr.farnell.com/invensense/mpu-6050/gyroscope-accelero-6-axes-i2c/dp/1864742

Altimètre : http://fr.farnell.com/freescale-semiconductor/mpl3115a2/pressure-sensor-20-110kpa-8lga/dp/2009084?ost=MPL3115A2&categoryId=700000004367

Explications norme BLE : chapters.comsoc.org/vancouver/BTLER3.pdf

http://www.argenox.com/bluetooth-low-energy-ble-v4-0-development/library/a-ble-advertising-primer/

----

Fichiers MATLAB

[[Fichier:Recuperation.zip]]

[[Fichier:Recuperation3.zip]]

== Rapport de Mi-projet ==

[[Fichier:CR_Miprojet_Sultana.pdf‎ ]]

P32 Récupération d'énergie pour balise BLE

2016-02-15T18:30:11Z

Qsultana : /* Semaine 17 (01/02/2016) */

== Objectif ==

Mon projet consiste à réaliser un système électronique autonome, composé de différents capteurs et capable de recueillir et de transmettre les données mémorisées vers un système centralisé.

== Etude préalable ==

L’énergie est le point de difficulté dans la réalisation de ce projet. Chaque élément devra être choisi non seulement pour ses performances mais également pour sa faible consommation.

== Organisation générale ==

Le système est organisé autour d’une source d’énergie, d’un contrôleur, de capteurs, de mémoire et d’un protocole de communication.

On cherche à minimiser l'énergie consommée par l'ensemble du système.

[[Fichier:P32Ensemble.PNG|250px|thumb|left|'''Architecture''']]

=== Chaine de l’énergie ===

L’énergie pour ce module autonome est constituée de quatre phases importantes :

[[Fichier:P32Energie.PNG]]

==== La récupération de l'énergie dans l'environnement ====

Il existe de nombreux moyens pour récupérer de l'énergie dans l'environnement. L'objectif est de trouver les sources les plus adaptées à l'environnement de l'application recherchée.

On peut citer:

* La récupération de l'énergie par différence de température

* Les panneaux photovoltaïques

* La récupération de l'énergie des ondes radio

* La Piézoélectricité

Dans ce projet nous utiliserons la piézoélectricité, le module de récupération ayant déjà fait partie d'une étude de IRCICA précédent le projet.

==== Le stockage de l’énergie ====

Le choix du système de stockage de l'énergie constitue une partie importante de la réalisation du système.
La problématique de cette partie sera de déterminer quel type de stockage nous utiliserons : batterie, super-capacité ou un hybride et de les dimensionner.
Il faudra tenir compte des problèmes de décharge partielle influent sur la durée de vie du stockage.

==== Le management/mise en forme de l’énergie ====

L'objectif de cette partie est d'étudier la nécessité de la mise en place d'une régulation tout en préservant des contraintes de consommation très faibles.

==== L'utilisation de l'énergie mise en forme ====

On cherche à minimiser l'énergie consommée par l'ensemble du système.

=== Contrôleur ===

Le microprocesseur : il existe différents types de microprocesseurs. L'objectif est de choisir un support capable de consommer un minimum d'énergie tout en conservant une taille minimale. Nous avons déjà utilisé dans d'autres projets des micro-contrôleurs de type Arduino et Raspberry pie. Ceux-ci ont pour avantage d’être prêts à l'emploi et faciles de prise en main. On peut s’orienter également vers un contrôleur ultra low power comme le STM32L4.

{| class="wikitable centre" width="80%"
|+
|-
! scope=col |
! scope=col | Consommation
! scope=col | Facilité de développement
! scope=col | Miniaturisation
|-
| width="33%" |
<center>Arduino</center>
| width="34%" |
<center>faible à très faible</center>
| width="33%" |
<center>bonne</center>
| width="33%" |
<center>faible</center>
|-
| width="33%" |
<center>Raspberry pi</center>
| width="34%" |
<center>importante</center>
| width="34%" |
<center>très bonne</center>
| width="34%" |
<center>très faible</center>
|-
| width="33%" |
<center>Ultra low power</center>
| width="34%" |
<center>très, très faible</center>
| width="33%" |
<center>difficile</center>
| width="33%" |
<center>forte</center>
|}

=== Capteurs ===

On peut imaginer différents types de capteurs :

* Accéléromètre

* Gyroscope

* Pression atmosphérique et altitude

* Température

* GPS

=== Mémoire ===

Le système doit être autonome et donc conserver un minimum de mesures pour les cas où la connexion est impossible. La mémoire doit être dimensionnée en fonction du nombre de capteurs, l’intervalle d’acquisition et le temps maximum avant connexion au système centralisé.

=== Protocole de communication ===

Un protocole de communication : dans un premier temps, nous nous concentrons sur le protocole BLE (Bluetooth Low Energie). Ce protocole étant standardisé, il nous permettra de recueillir de la documentation et réaliser des tests de consommation rapides.

== Planning prévisionnel ==

[[Fichier:P32Gant.PNG]]

==Suivi de l'avancement du Projet==
===Semaine 1 (28/09/2015)===

* Rencontre avec Monsieur Boe et Monsieur Giraud

* Présentation du projet

* Recherche documentaire

* Etablissement du cahier des charges

===Semaine 2 (05/10/2015)===

Recherche documentaire sur la consommation estimée des différents éléments.

{| class="wikitable centre" width="80%"
|+
|-
! scope=col | '''Contrôleur'''
! scope=col | Consommation Active
! scope=col | Consommation Inactive
! scope=col | Prix
|-
| width="33%" |
<center>Arduino Pro Mini 328 </center>
| width="34%" |
<center> 7mA (1 capteur)</center>
| width="33%" |
<center>4.5µA</center>
| width="33%" |
<center>Disponible</center>
|-
| width="33%" |
<center>STM32L4 Series (STM32L476JE)</center>
| width="34%" |
<center> 100 μA/MHz</center>
| width="33%" |
<center>120 nA</center>
| width="33%" |
<center>$5</center>
|-
| width="33%" |
<center>Raspberry</center>
| width="34%" |
<center> 200mA </center>
| width="33%" |
<center>200mA</center>
| width="33%" |
<center>Disponible</center>
|}

{| class="wikitable centre" width="80%"
|+
|-
! scope=col | '''Module BLE'''
! scope=col | Consommation
! scope=col | Options d'alimentation
! scope=col | Prix
|-
| width="33%" |
<center>BLE Mini</center>
| width="34%" |
<center> 15 mA </center>
| width="33%" |
<center>3.4V à 11V VIN / 5V USB / Coin Cell Battery (2025 or 2032) / 3.7V Li-ion Battery</center>
| width="33%" |
<center>$17</center>
|}

* <s> Le système Mini Arduino/ BLE Mini me semble être un bon compromis entre facilité d’intégration, consommation d'énergie et miniaturisation du système.</s> (Choix à discuter à la réunion du Merdredi 07/10)
* Choix du module RFduino

{| class="wikitable centre" width="80%"
|+
|-
! scope=col | '''Capteurs'''
! scope=col | Modèle
! scope=col | Alimentation min/max
! scope=col | Prix
|-
| width="33%" |
<center>Température</center>
| width="34%" |
<center> TMP36GT9Z </center>
| width="33%" |
<center>2.7V/5.5V</center>
| width="33%" |
<center>1,46 €</center>
|-
| width="33%" |
<center>Accéléromètre</center>
| width="34%" |
<center> ADXL345BCCZ </center>
| width="33%" |
<center>2V/3.6V</center>
| width="33%" |
<center>5,54 €</center>
|-
| width="33%" |
<center>Gyroscope+Accéléromètre</center>
| width="34%" |
<center> MPU-6050</center>
| width="33%" |
<center>2.5V/3.6V</center>
| width="33%" |
<center>15,73 €</center>
|-
| width="33%" |
<center>Pression atmosphérique / Altitude</center>
| width="34%" |
<center> MPL3115A2 </center>
| width="33%" |
<center>1.95V/3.6V</center>
| width="33%" |
<center>2,65 €</center>
|}

* Pour minimiser les pertes on cherche a travailler avec une tension d'alimentation la plus faible possible. Je propose de travailler avec une tension d'alimentation de 3,3V (Validé à discuter à la réunion du Merdredi 07/10)

* Le système de récupération d'énergie fonctionnant sur la base d'un mouvement, j'ai choisi l'ensemble des capteur ci dessus qui me semble être adapté à l'intégration dans un système en mouvement. (Validé à discuter à la réunion du Merdredi 07/10)

* Récupération des modules RFduino, prise en main

===Semaine 3 (12/10/2015)===

* Installation des librairies

* Visualisation d'exemples

* Tests d'implantation du code source du projet P14: Aimant intelligent de la session IMA4: 2014/2015

* Optimisation du code pour la réduction de la consommation d'énergie

* Recherches sur d'autres composants dans l'optique d'une consommation toujours plus faible

{| class="wikitable centre" width="80%"
|+
|-
! scope=col | '''Capteurs'''
! scope=col | Modèle
! scope=col | Alimentation min/max
! scope=col | Prix
! scope=col | Consommation (typ/max)
|-
| width="33%" |
<center>Température</center>
| width="34%" |
<center> STLM20W87F </center>
| width="33%" |
<center>2.4V/5.5V</center>
| width="33%" |
<center> 0,775 € </center>
| width="33%" |
<center> 4.8 μA/8.0 μA </center>
|}

'''Calcul théorique de la consommation énergétique du module BLE + RFD22301'''

Mode "endormi" : ARM CPU Running Current + Output standard drive current = 4 + 0.5 = 4.5mA

Mode "acquisition": ARM CPU Running Current + Output high drive current = 5 + 4 = 9mA

Mode "transmission" : ARM CPU Running Current + Transmit Current + Output standard drive current = 4 + 0.5 + 12 = 16.5mA

http://www.rfduino.com/wp-content/uploads/2014/03/RFD22301.Data_.Sheet_.11.24.13_11.38PM.pdf

'''Code possible du mode "endormi"'''

pinMode(5, INPUT);
RFduino_pinWake(5, HIGH);

RFduino_ULPDelay(INFINITE);
if (RFduino_pinWoke(5))
{
state = ! state;
RFduinoGZLL.sendToHost(state);
}

http://forum.rfduino.com/index.php?topic=385.0

===Semaine 4 (19/10/2015)===

* Réunion du 21/10

* Réalisation de tests

* Ajustement du nombre de capteurs : dans un premier temps on utilisera le capteur de température puis l'accéléromètre

* Discussion sur le bac de test et méthodes de test : résistance de visualisation, chronométrage du temps de transmission, vitesse du processeur

* Réalisation des premiers relevés

===Semaine 5 (26/10/2015)===

* Recherche bibliographique sur les modes d'endormissement du module RFduino

* Essais de codes utilisant un mode d'endormissement plus profond

* Réalisation de graphique de l'énergie utilisée par le module lors de la transmission d'un message par le module BLE.

* Recherches sur des méthodes de programmation pour la diminution de la vitesse processeur

[[Fichier:P32Montage.jpg|250px|thumb|left|'''Montage de test''']]
[[Fichier:P32resultats.jpg|250px|thumb|center|'''Visualisation du courant consommé lors d'envoi toutes les 10ms''']]

* On visualise à l'oscilloscope des pic d'envoi et des pic d'avertissement de la balise BLE, on peut ainsi déduire la puissance nécessaire de chaque action

===Semaine 6 (02/11/2015)===

* Test de diminution de la vitesse processeur

* Réalisation de graphique démontrant l'impact de la réduction de la vitesse processeur sur l'énergie consommée et déduction d'une vitesse optimale pour notre application

* Réunion du 4/11

Définition d'objectifs : Création d'un fichier excel permettant de caractériser les coûts en énergies de chaque étapes de fonctionnement du système.

* Création d'un environnement de test "normé" ( Pour éviter les variations de mesures on réalise un banc et on applique les mêmes conditions de test pour chaque essai)

* Recherche bibliographique sur la norme BLE : recherche du temps maximum entre deux "avertissements" de la balise BLE

===Semaine 7 (09/11/2015)===
* Explication du principe de communication BLE pour l'exploitation des résultats

[[Fichier:Freq.PNG]]

Nous nous intéressons dans notre projet à "l'observateur". Cet objet peut avoir trois états : stand-by, advertising et en communication.

[[Fichier:Brod2.png]]

Dans le mode "Advertising" le système peut :

- Avertir le système récepteur de la proximité d'un capteur

- Avertir de la présence à un appareil souhaitant ce connecter

- Ce reconnecter de façon asynchrone

===Semaine 8 (16/11/2015)===

Analyse en détail d'une trame BLE

[[Fichier:Com.PNG]]

On constate que pendant la durée de la trame il y a un échange entre les deux objets appairé. On s’intéresse ici uniquement aux actions "Slave Tx". Le but étant d'identifier la durée et le courant consommé par ces actions pour obtenir des valeurs en joules.

[[Fichier:SchemaCom.PNG]]

On constate donc deux phases :

- Advertising event

- Connexion event

Nous allons essayer de retrouver et quantifié l'énergie consommé dans ces deux phases.

===Semaine 9 (23/11/2015)===

Lors de cette semaine nous avons effectué des tests en respectant une procédure de test précise. En effet les valeurs des courants que nous relevons sont très petites aussi chaque variation du montage est susceptible de perturber les valeurs.

[[Fichier:P32Conne.jpg|250px|thumb|left|'''Phase connexion''']]

[[Fichier:Avertissement.jpg|250px|thumb|center|'''Phase Advertising''']]

===Semaine 10 (30/11/2015)===

- On cherche a diminuer légèrement la consommation par des modifications logiciel :

Réduction de la puissance de la radio BLE : Diminution de la portée

Augmentation de la fréquence d'advertising : tant que la fréquence d'advetising est inférieure a cette de relevé des capteurs on s'assure que la donnée envoyée est toujours mise à jour.

[[Fichier:Pwl20-envoi.jpg|250px|thumb|left|'''Avec modification logiciel''']]

[[Fichier:Sans-pwlvl.jpg|250px|thumb|center|'''Sans modification logiciel''']]

- On concentre nos résultats dans un tableau récapitulatif en vue du dimensionnement de la batterie du système

[[Fichier:P32tbresul.PNG]]

===Semaine 11 (07/12/2015)===

Tests d'intégration de plusieurs capteur et observations des modification de la consommation des ADC et de la durée/consommation de la transmission.

Réunion de vérification des tests.

Mise en évidence de la dualité consommation d'énergie - Temps de réponse du système

En effet chaque "Advertisement" consomme une quantité d'énergie nous pouvons gérer l'espacement entre ceux-ci mais plus ce temps serra élevé plus il faudra de temps pour ce connecter à ce périphérique.

* Rédaction d'un rapport de test

* Rédaction du rapport de pré soutenance

===Semaine 12 (14/12/2015)===

* Recherches de solutions pour l'amélioration du modèle
* Recherches Matlab pour effectuer une analyse statistique d’avènements aléatoires sur la liaison

===Semaine 13 (04/01/2016)===

*Amélioration du modèle

L’amélioration du modèle est réalisée en tenant compte des facteurs influent sur la qualité de la transmission.

* Utilisation d'un picoscope : appareil permettant l’acquisition sur ordinateur de plusieurs formes d'ondes.
Ainsi grâce a un pico scope utilisé à l’IRCICA j’ai pu relever de nombreux échantillons nécessaire a une étude statistique des surcoûts en énergie.

[[Fichier:Montagemulti.jpg|250px|thumb|left|'''Montage multi récepteur''']]

===Semaine 14 (11/01/2016)===

* Compilation des résultats

* Exploitation Matlab

[[Fichier:Emistbrecap.PNG]]

===Semaine 15 (18/01/2016)===

Principe de fonctionnement du récupérateur d’énergie

Le récupérateur d’énergie fonctionne grâce à un patch piezo. Ce patch est capable de produire un courent à partir de la vélocité d’une impulsion suivent la formule :

[[Fichier:Equapiezo.PNG]]

[[Fichier:Modelepizo.PNG|250px|thumb|left|'''Modèle simplifié du patch piezo''']]

Pour récupérer de l’énergie il est couplé au système suivent :

[[Fichier:montagepiezo.PNG]]

La puissance du système est définie par :

P=V*im

L’énergie s’exprime alors :

[[Fichier:Equaenergie.PNG]]

L’énergie produite par le système est donc dépendante de la tension d’alimentation V de la constante électromécanique N et du choc produit sur le patch piezo.
Une impulsion sur le capteur piezo est de la forme :

La dérivée par rapport au temps de cette impulsion est donc de la forme :

Il est donc important de « fenêtrer » la tension pour ne récupérer que la partie positive.
Ce fenêtrage ainsi que la fréquence de commutation du hacheur est assurée par un microcontrôleur.

Dans la suite de notre étude nous ne tiendrons pas compte de la consommation de celui-ci.

===Semaine 16 (25/01/2016)===

* Réflexions sur le prototypage

* Présentation du récupérateur

* Mise en place du banc de test

* Premiers relevés

[[Fichier:Montagepiezo.jpg|250px|thumb|left|'''Montage piezo''']]
[[Fichier:Patchpiezo.jpg|250px|thumb|center|'''Patch piezo''']]

===Semaine 17 (01/02/2016)===

Test de la quantité d’énergie récupérée par un patch piezo

Méthodologie :

Channel rouge : Tension aux bornes du patch piezo. Ici on observe une fenêtre de tension de 4,5ms imposée par le microcontrôleur.

Channel vert : Tension aux bornes de la capacité C1 de 220nF
[[Fichier:Diffpot.png|250px|thumb|center|'''Tension patch piezo / Tension C1''']]

On constate qu’un choc sur le patch piezo produit une énergie suivent la formule, E = V * N * Δw
N étant une constante électromécanique, on va faire varier V pour évaluer le gain en énergie. Cependant Δw est généré par un choc d’un stylo sur le patch il n’est donc pas uniforme.
Nous utilisons donc une méthode statistique qui consiste à retirer deux extrémum et faire la moyenne de 10 mesures.

Nous obtenons la courbe suivante :

On constate que la courbe n’est pas linéaire comme l’aurai laissé supposer la formule. En effet jusqu’à 30V elle est linéaire croissante suivent l’équation :

Puis après 30V elle devient quadratique décroissante suivent la formule :

En effet la formule E = V * N * Δw néglige les pertes. Celles-ci deviennent plus importante a chaque augmentation de la tension d’alimentation.

On obtient donc un point de fonctionnement optimal a 30V pour notre système. Ce qui impose que notre système soit équipé d’une source de tension en conséquence.

===Semaine 18 (08/02/2016)===

*Réalisation de nombreux tests pour confirmation de la caractéristique

[[Fichier:P32Courbe.png]]

===Semaine 19 (15/02/2016)===
===Semaine 20 (22/02/2016)===

== Annexes ==

Consommation du STM32L4 Series : http://www.st.com/web/en/catalog/mmc/FM141/SC1169/SS1580?sc=stm32l4

Réduction de la consommation de l'Arduino : http://www.home-automation-community.com/arduino-low-power-how-to-run-atmega328p-for-a-year-on-coin-cell-battery/

Consommation Raspberry : https://www.raspberrypi.org/help/faqs/

Module BLE : http://redbearlab.com/blemini/

Accéléromètre : http://fr.farnell.com/analog-devices/adxl345bccz/accelerometre-3-axes-14lga/dp/1853935

Capteur température : http://fr.farnell.com/analog-devices/tmp36gt9z/capteur-temp-to-92-3/dp/1438760?ost=TMP36GT9Z
ou http://fr.farnell.com/stmicroelectronics/stlm20w87f/capteur-de-temperature-analog/dp/1391131

Accéléromètre + Gyroscope : http://fr.farnell.com/invensense/mpu-6050/gyroscope-accelero-6-axes-i2c/dp/1864742

Altimètre : http://fr.farnell.com/freescale-semiconductor/mpl3115a2/pressure-sensor-20-110kpa-8lga/dp/2009084?ost=MPL3115A2&categoryId=700000004367

Explications norme BLE : chapters.comsoc.org/vancouver/BTLER3.pdf

http://www.argenox.com/bluetooth-low-energy-ble-v4-0-development/library/a-ble-advertising-primer/

----

Fichiers MATLAB

[[Fichier:Recuperation.zip]]

[[Fichier:Recuperation3.zip]]

== Rapport de Mi-projet ==

[[Fichier:CR_Miprojet_Sultana.pdf‎ ]]

P32 Récupération d'énergie pour balise BLE

2016-02-11T14:50:14Z

Qsultana : /* Semaine 18 (08/02/2016) */

== Objectif ==

Mon projet consiste à réaliser un système électronique autonome, composé de différents capteurs et capable de recueillir et de transmettre les données mémorisées vers un système centralisé.

== Etude préalable ==

L’énergie est le point de difficulté dans la réalisation de ce projet. Chaque élément devra être choisi non seulement pour ses performances mais également pour sa faible consommation.

== Organisation générale ==

Le système est organisé autour d’une source d’énergie, d’un contrôleur, de capteurs, de mémoire et d’un protocole de communication.

On cherche à minimiser l'énergie consommée par l'ensemble du système.

[[Fichier:P32Ensemble.PNG|250px|thumb|left|'''Architecture''']]

=== Chaine de l’énergie ===

L’énergie pour ce module autonome est constituée de quatre phases importantes :

[[Fichier:P32Energie.PNG]]

==== La récupération de l'énergie dans l'environnement ====

Il existe de nombreux moyens pour récupérer de l'énergie dans l'environnement. L'objectif est de trouver les sources les plus adaptées à l'environnement de l'application recherchée.

On peut citer:

* La récupération de l'énergie par différence de température

* Les panneaux photovoltaïques

* La récupération de l'énergie des ondes radio

* La Piézoélectricité

Dans ce projet nous utiliserons la piézoélectricité, le module de récupération ayant déjà fait partie d'une étude de IRCICA précédent le projet.

==== Le stockage de l’énergie ====

Le choix du système de stockage de l'énergie constitue une partie importante de la réalisation du système.
La problématique de cette partie sera de déterminer quel type de stockage nous utiliserons : batterie, super-capacité ou un hybride et de les dimensionner.
Il faudra tenir compte des problèmes de décharge partielle influent sur la durée de vie du stockage.

==== Le management/mise en forme de l’énergie ====

L'objectif de cette partie est d'étudier la nécessité de la mise en place d'une régulation tout en préservant des contraintes de consommation très faibles.

==== L'utilisation de l'énergie mise en forme ====

On cherche à minimiser l'énergie consommée par l'ensemble du système.

=== Contrôleur ===

Le microprocesseur : il existe différents types de microprocesseurs. L'objectif est de choisir un support capable de consommer un minimum d'énergie tout en conservant une taille minimale. Nous avons déjà utilisé dans d'autres projets des micro-contrôleurs de type Arduino et Raspberry pie. Ceux-ci ont pour avantage d’être prêts à l'emploi et faciles de prise en main. On peut s’orienter également vers un contrôleur ultra low power comme le STM32L4.

{| class="wikitable centre" width="80%"
|+
|-
! scope=col |
! scope=col | Consommation
! scope=col | Facilité de développement
! scope=col | Miniaturisation
|-
| width="33%" |
<center>Arduino</center>
| width="34%" |
<center>faible à très faible</center>
| width="33%" |
<center>bonne</center>
| width="33%" |
<center>faible</center>
|-
| width="33%" |
<center>Raspberry pi</center>
| width="34%" |
<center>importante</center>
| width="34%" |
<center>très bonne</center>
| width="34%" |
<center>très faible</center>
|-
| width="33%" |
<center>Ultra low power</center>
| width="34%" |
<center>très, très faible</center>
| width="33%" |
<center>difficile</center>
| width="33%" |
<center>forte</center>
|}

=== Capteurs ===

On peut imaginer différents types de capteurs :

* Accéléromètre

* Gyroscope

* Pression atmosphérique et altitude

* Température

* GPS

=== Mémoire ===

Le système doit être autonome et donc conserver un minimum de mesures pour les cas où la connexion est impossible. La mémoire doit être dimensionnée en fonction du nombre de capteurs, l’intervalle d’acquisition et le temps maximum avant connexion au système centralisé.

=== Protocole de communication ===

Un protocole de communication : dans un premier temps, nous nous concentrons sur le protocole BLE (Bluetooth Low Energie). Ce protocole étant standardisé, il nous permettra de recueillir de la documentation et réaliser des tests de consommation rapides.

== Planning prévisionnel ==

[[Fichier:P32Gant.PNG]]

==Suivi de l'avancement du Projet==
===Semaine 1 (28/09/2015)===

* Rencontre avec Monsieur Boe et Monsieur Giraud

* Présentation du projet

* Recherche documentaire

* Etablissement du cahier des charges

===Semaine 2 (05/10/2015)===

Recherche documentaire sur la consommation estimée des différents éléments.

{| class="wikitable centre" width="80%"
|+
|-
! scope=col | '''Contrôleur'''
! scope=col | Consommation Active
! scope=col | Consommation Inactive
! scope=col | Prix
|-
| width="33%" |
<center>Arduino Pro Mini 328 </center>
| width="34%" |
<center> 7mA (1 capteur)</center>
| width="33%" |
<center>4.5µA</center>
| width="33%" |
<center>Disponible</center>
|-
| width="33%" |
<center>STM32L4 Series (STM32L476JE)</center>
| width="34%" |
<center> 100 μA/MHz</center>
| width="33%" |
<center>120 nA</center>
| width="33%" |
<center>$5</center>
|-
| width="33%" |
<center>Raspberry</center>
| width="34%" |
<center> 200mA </center>
| width="33%" |
<center>200mA</center>
| width="33%" |
<center>Disponible</center>
|}

{| class="wikitable centre" width="80%"
|+
|-
! scope=col | '''Module BLE'''
! scope=col | Consommation
! scope=col | Options d'alimentation
! scope=col | Prix
|-
| width="33%" |
<center>BLE Mini</center>
| width="34%" |
<center> 15 mA </center>
| width="33%" |
<center>3.4V à 11V VIN / 5V USB / Coin Cell Battery (2025 or 2032) / 3.7V Li-ion Battery</center>
| width="33%" |
<center>$17</center>
|}

* <s> Le système Mini Arduino/ BLE Mini me semble être un bon compromis entre facilité d’intégration, consommation d'énergie et miniaturisation du système.</s> (Choix à discuter à la réunion du Merdredi 07/10)
* Choix du module RFduino

{| class="wikitable centre" width="80%"
|+
|-
! scope=col | '''Capteurs'''
! scope=col | Modèle
! scope=col | Alimentation min/max
! scope=col | Prix
|-
| width="33%" |
<center>Température</center>
| width="34%" |
<center> TMP36GT9Z </center>
| width="33%" |
<center>2.7V/5.5V</center>
| width="33%" |
<center>1,46 €</center>
|-
| width="33%" |
<center>Accéléromètre</center>
| width="34%" |
<center> ADXL345BCCZ </center>
| width="33%" |
<center>2V/3.6V</center>
| width="33%" |
<center>5,54 €</center>
|-
| width="33%" |
<center>Gyroscope+Accéléromètre</center>
| width="34%" |
<center> MPU-6050</center>
| width="33%" |
<center>2.5V/3.6V</center>
| width="33%" |
<center>15,73 €</center>
|-
| width="33%" |
<center>Pression atmosphérique / Altitude</center>
| width="34%" |
<center> MPL3115A2 </center>
| width="33%" |
<center>1.95V/3.6V</center>
| width="33%" |
<center>2,65 €</center>
|}

* Pour minimiser les pertes on cherche a travailler avec une tension d'alimentation la plus faible possible. Je propose de travailler avec une tension d'alimentation de 3,3V (Validé à discuter à la réunion du Merdredi 07/10)

* Le système de récupération d'énergie fonctionnant sur la base d'un mouvement, j'ai choisi l'ensemble des capteur ci dessus qui me semble être adapté à l'intégration dans un système en mouvement. (Validé à discuter à la réunion du Merdredi 07/10)

* Récupération des modules RFduino, prise en main

===Semaine 3 (12/10/2015)===

* Installation des librairies

* Visualisation d'exemples

* Tests d'implantation du code source du projet P14: Aimant intelligent de la session IMA4: 2014/2015

* Optimisation du code pour la réduction de la consommation d'énergie

* Recherches sur d'autres composants dans l'optique d'une consommation toujours plus faible

{| class="wikitable centre" width="80%"
|+
|-
! scope=col | '''Capteurs'''
! scope=col | Modèle
! scope=col | Alimentation min/max
! scope=col | Prix
! scope=col | Consommation (typ/max)
|-
| width="33%" |
<center>Température</center>
| width="34%" |
<center> STLM20W87F </center>
| width="33%" |
<center>2.4V/5.5V</center>
| width="33%" |
<center> 0,775 € </center>
| width="33%" |
<center> 4.8 μA/8.0 μA </center>
|}

'''Calcul théorique de la consommation énergétique du module BLE + RFD22301'''

Mode "endormi" : ARM CPU Running Current + Output standard drive current = 4 + 0.5 = 4.5mA

Mode "acquisition": ARM CPU Running Current + Output high drive current = 5 + 4 = 9mA

Mode "transmission" : ARM CPU Running Current + Transmit Current + Output standard drive current = 4 + 0.5 + 12 = 16.5mA

http://www.rfduino.com/wp-content/uploads/2014/03/RFD22301.Data_.Sheet_.11.24.13_11.38PM.pdf

'''Code possible du mode "endormi"'''

pinMode(5, INPUT);
RFduino_pinWake(5, HIGH);

RFduino_ULPDelay(INFINITE);
if (RFduino_pinWoke(5))
{
state = ! state;
RFduinoGZLL.sendToHost(state);
}

http://forum.rfduino.com/index.php?topic=385.0

===Semaine 4 (19/10/2015)===

* Réunion du 21/10

* Réalisation de tests

* Ajustement du nombre de capteurs : dans un premier temps on utilisera le capteur de température puis l'accéléromètre

* Discussion sur le bac de test et méthodes de test : résistance de visualisation, chronométrage du temps de transmission, vitesse du processeur

* Réalisation des premiers relevés

===Semaine 5 (26/10/2015)===

* Recherche bibliographique sur les modes d'endormissement du module RFduino

* Essais de codes utilisant un mode d'endormissement plus profond

* Réalisation de graphique de l'énergie utilisée par le module lors de la transmission d'un message par le module BLE.

* Recherches sur des méthodes de programmation pour la diminution de la vitesse processeur

[[Fichier:P32Montage.jpg|250px|thumb|left|'''Montage de test''']]
[[Fichier:P32resultats.jpg|250px|thumb|center|'''Visualisation du courant consommé lors d'envoi toutes les 10ms''']]

* On visualise à l'oscilloscope des pic d'envoi et des pic d'avertissement de la balise BLE, on peut ainsi déduire la puissance nécessaire de chaque action

===Semaine 6 (02/11/2015)===

* Test de diminution de la vitesse processeur

* Réalisation de graphique démontrant l'impact de la réduction de la vitesse processeur sur l'énergie consommée et déduction d'une vitesse optimale pour notre application

* Réunion du 4/11

Définition d'objectifs : Création d'un fichier excel permettant de caractériser les coûts en énergies de chaque étapes de fonctionnement du système.

* Création d'un environnement de test "normé" ( Pour éviter les variations de mesures on réalise un banc et on applique les mêmes conditions de test pour chaque essai)

* Recherche bibliographique sur la norme BLE : recherche du temps maximum entre deux "avertissements" de la balise BLE

===Semaine 7 (09/11/2015)===
* Explication du principe de communication BLE pour l'exploitation des résultats

[[Fichier:Freq.PNG]]

Nous nous intéressons dans notre projet à "l'observateur". Cet objet peut avoir trois états : stand-by, advertising et en communication.

[[Fichier:Brod2.png]]

Dans le mode "Advertising" le système peut :

- Avertir le système récepteur de la proximité d'un capteur

- Avertir de la présence à un appareil souhaitant ce connecter

- Ce reconnecter de façon asynchrone

===Semaine 8 (16/11/2015)===

Analyse en détail d'une trame BLE

[[Fichier:Com.PNG]]

On constate que pendant la durée de la trame il y a un échange entre les deux objets appairé. On s’intéresse ici uniquement aux actions "Slave Tx". Le but étant d'identifier la durée et le courant consommé par ces actions pour obtenir des valeurs en joules.

[[Fichier:SchemaCom.PNG]]

On constate donc deux phases :

- Advertising event

- Connexion event

Nous allons essayer de retrouver et quantifié l'énergie consommé dans ces deux phases.

===Semaine 9 (23/11/2015)===

Lors de cette semaine nous avons effectué des tests en respectant une procédure de test précise. En effet les valeurs des courants que nous relevons sont très petites aussi chaque variation du montage est susceptible de perturber les valeurs.

[[Fichier:P32Conne.jpg|250px|thumb|left|'''Phase connexion''']]

[[Fichier:Avertissement.jpg|250px|thumb|center|'''Phase Advertising''']]

===Semaine 10 (30/11/2015)===

- On cherche a diminuer légèrement la consommation par des modifications logiciel :

Réduction de la puissance de la radio BLE : Diminution de la portée

Augmentation de la fréquence d'advertising : tant que la fréquence d'advetising est inférieure a cette de relevé des capteurs on s'assure que la donnée envoyée est toujours mise à jour.

[[Fichier:Pwl20-envoi.jpg|250px|thumb|left|'''Avec modification logiciel''']]

[[Fichier:Sans-pwlvl.jpg|250px|thumb|center|'''Sans modification logiciel''']]

- On concentre nos résultats dans un tableau récapitulatif en vue du dimensionnement de la batterie du système

[[Fichier:P32tbresul.PNG]]

===Semaine 11 (07/12/2015)===

Tests d'intégration de plusieurs capteur et observations des modification de la consommation des ADC et de la durée/consommation de la transmission.

Réunion de vérification des tests.

Mise en évidence de la dualité consommation d'énergie - Temps de réponse du système

En effet chaque "Advertisement" consomme une quantité d'énergie nous pouvons gérer l'espacement entre ceux-ci mais plus ce temps serra élevé plus il faudra de temps pour ce connecter à ce périphérique.

* Rédaction d'un rapport de test

* Rédaction du rapport de pré soutenance

===Semaine 12 (14/12/2015)===

* Recherches de solutions pour l'amélioration du modèle
* Recherches Matlab pour effectuer une analyse statistique d’avènements aléatoires sur la liaison

===Semaine 13 (04/01/2016)===

*Amélioration du modèle

L’amélioration du modèle est réalisée en tenant compte des facteurs influent sur la qualité de la transmission.

* Utilisation d'un picoscope : appareil permettant l’acquisition sur ordinateur de plusieurs formes d'ondes.
Ainsi grâce a un pico scope utilisé à l’IRCICA j’ai pu relever de nombreux échantillons nécessaire a une étude statistique des surcoûts en énergie.

[[Fichier:Montagemulti.jpg|250px|thumb|left|'''Montage multi récepteur''']]

===Semaine 14 (11/01/2016)===

* Compilation des résultats

* Exploitation Matlab

[[Fichier:Emistbrecap.PNG]]

===Semaine 15 (18/01/2016)===

Principe de fonctionnement du récupérateur d’énergie

Le récupérateur d’énergie fonctionne grâce à un patch piezo. Ce patch est capable de produire un courent à partir de la vélocité d’une impulsion suivent la formule :

[[Fichier:Equapiezo.PNG]]

[[Fichier:Modelepizo.PNG|250px|thumb|left|'''Modèle simplifié du patch piezo''']]

Pour récupérer de l’énergie il est couplé au système suivent :

[[Fichier:montagepiezo.PNG]]

La puissance du système est définie par :

P=V*im

L’énergie s’exprime alors :

[[Fichier:Equaenergie.PNG]]

L’énergie produite par le système est donc dépendante de la tension d’alimentation V de la constante électromécanique N et du choc produit sur le patch piezo.
Une impulsion sur le capteur piezo est de la forme :

La dérivée par rapport au temps de cette impulsion est donc de la forme :

Il est donc important de « fenêtrer » la tension pour ne récupérer que la partie positive.
Ce fenêtrage ainsi que la fréquence de commutation du hacheur est assurée par un microcontrôleur.

Dans la suite de notre étude nous ne tiendrons pas compte de la consommation de celui-ci.

===Semaine 16 (25/01/2016)===

* Réflexions sur le prototypage

* Présentation du récupérateur

* Mise en place du banc de test

* Premiers relevés

[[Fichier:Montagepiezo.jpg|250px|thumb|left|'''Montage piezo''']]
[[Fichier:Patchpiezo.jpg|250px|thumb|center|'''Patch piezo''']]

===Semaine 17 (01/02/2016)===

Test de la quantité d’énergie récupérée par un patch piezo

Méthodologie :

Channel rouge : Tension aux bornes du patch piezo. Ici on observe une fenêtre de tension de 4,5ms imposée par le microcontrôleur.

Channel vert : Tension aux bornes de la capacité C1 de 220nF
[[Fichier:Diffpot.png|250px|thumb|center]]

On constate qu’un choc sur le patch piezo produit une énergie suivent la formule, E = V * N * Δw
N étant une constante électromécanique, on va faire varier V pour évaluer le gain en énergie. Cependant Δw est généré par un choc d’un stylo sur le patch il n’est donc pas uniforme.
Nous utilisons donc une méthode statistique qui consiste à retirer deux extrémum et faire la moyenne de 10 mesures.

Nous obtenons la courbe suivante :

On constate que la courbe n’est pas linéaire comme l’aurai laissé supposer la formule. En effet jusqu’à 30V elle est linéaire croissante suivent l’équation :

Puis après 30V elle devient quadratique décroissante suivent la formule :

En effet la formule E = V * N * Δw néglige les pertes. Celles-ci deviennent plus importante a chaque augmentation de la tension d’alimentation.

On obtient donc un point de fonctionnement optimal a 30V pour notre système. Ce qui impose que notre système soit équipé d’une source de tension en conséquence.

===Semaine 18 (08/02/2016)===

*Réalisation de nombreux tests pour confirmation de la caractéristique

[[Fichier:P32Courbe.png]]

===Semaine 19 (15/02/2016)===
===Semaine 20 (22/02/2016)===

== Annexes ==

Consommation du STM32L4 Series : http://www.st.com/web/en/catalog/mmc/FM141/SC1169/SS1580?sc=stm32l4

Réduction de la consommation de l'Arduino : http://www.home-automation-community.com/arduino-low-power-how-to-run-atmega328p-for-a-year-on-coin-cell-battery/

Consommation Raspberry : https://www.raspberrypi.org/help/faqs/

Module BLE : http://redbearlab.com/blemini/

Accéléromètre : http://fr.farnell.com/analog-devices/adxl345bccz/accelerometre-3-axes-14lga/dp/1853935

Capteur température : http://fr.farnell.com/analog-devices/tmp36gt9z/capteur-temp-to-92-3/dp/1438760?ost=TMP36GT9Z
ou http://fr.farnell.com/stmicroelectronics/stlm20w87f/capteur-de-temperature-analog/dp/1391131

Accéléromètre + Gyroscope : http://fr.farnell.com/invensense/mpu-6050/gyroscope-accelero-6-axes-i2c/dp/1864742

Altimètre : http://fr.farnell.com/freescale-semiconductor/mpl3115a2/pressure-sensor-20-110kpa-8lga/dp/2009084?ost=MPL3115A2&categoryId=700000004367

Explications norme BLE : chapters.comsoc.org/vancouver/BTLER3.pdf

http://www.argenox.com/bluetooth-low-energy-ble-v4-0-development/library/a-ble-advertising-primer/

----

Fichiers MATLAB

[[Fichier:Recuperation.zip]]

[[Fichier:Recuperation3.zip]]

== Rapport de Mi-projet ==

[[Fichier:CR_Miprojet_Sultana.pdf‎ ]]

Fichier:P32Courbe.png

2016-02-11T14:47:44Z

Qsultana : P32 : Courbe caractéristique de l'énergie récupérée par le montage en fonction de la tension d'alimentation

P32 : Courbe caractéristique de l'énergie récupérée par le montage en fonction de la tension d'alimentation

P32 Récupération d'énergie pour balise BLE

2016-02-11T11:01:36Z

Qsultana : /* Annexes */

== Objectif ==

Mon projet consiste à réaliser un système électronique autonome, composé de différents capteurs et capable de recueillir et de transmettre les données mémorisées vers un système centralisé.

== Etude préalable ==

L’énergie est le point de difficulté dans la réalisation de ce projet. Chaque élément devra être choisi non seulement pour ses performances mais également pour sa faible consommation.

== Organisation générale ==

Le système est organisé autour d’une source d’énergie, d’un contrôleur, de capteurs, de mémoire et d’un protocole de communication.

On cherche à minimiser l'énergie consommée par l'ensemble du système.

[[Fichier:P32Ensemble.PNG|250px|thumb|left|'''Architecture''']]

=== Chaine de l’énergie ===

L’énergie pour ce module autonome est constituée de quatre phases importantes :

[[Fichier:P32Energie.PNG]]

==== La récupération de l'énergie dans l'environnement ====

Il existe de nombreux moyens pour récupérer de l'énergie dans l'environnement. L'objectif est de trouver les sources les plus adaptées à l'environnement de l'application recherchée.

On peut citer:

* La récupération de l'énergie par différence de température

* Les panneaux photovoltaïques

* La récupération de l'énergie des ondes radio

* La Piézoélectricité

Dans ce projet nous utiliserons la piézoélectricité, le module de récupération ayant déjà fait partie d'une étude de IRCICA précédent le projet.

==== Le stockage de l’énergie ====

Le choix du système de stockage de l'énergie constitue une partie importante de la réalisation du système.
La problématique de cette partie sera de déterminer quel type de stockage nous utiliserons : batterie, super-capacité ou un hybride et de les dimensionner.
Il faudra tenir compte des problèmes de décharge partielle influent sur la durée de vie du stockage.

==== Le management/mise en forme de l’énergie ====

L'objectif de cette partie est d'étudier la nécessité de la mise en place d'une régulation tout en préservant des contraintes de consommation très faibles.

==== L'utilisation de l'énergie mise en forme ====

On cherche à minimiser l'énergie consommée par l'ensemble du système.

=== Contrôleur ===

Le microprocesseur : il existe différents types de microprocesseurs. L'objectif est de choisir un support capable de consommer un minimum d'énergie tout en conservant une taille minimale. Nous avons déjà utilisé dans d'autres projets des micro-contrôleurs de type Arduino et Raspberry pie. Ceux-ci ont pour avantage d’être prêts à l'emploi et faciles de prise en main. On peut s’orienter également vers un contrôleur ultra low power comme le STM32L4.

{| class="wikitable centre" width="80%"
|+
|-
! scope=col |
! scope=col | Consommation
! scope=col | Facilité de développement
! scope=col | Miniaturisation
|-
| width="33%" |
<center>Arduino</center>
| width="34%" |
<center>faible à très faible</center>
| width="33%" |
<center>bonne</center>
| width="33%" |
<center>faible</center>
|-
| width="33%" |
<center>Raspberry pi</center>
| width="34%" |
<center>importante</center>
| width="34%" |
<center>très bonne</center>
| width="34%" |
<center>très faible</center>
|-
| width="33%" |
<center>Ultra low power</center>
| width="34%" |
<center>très, très faible</center>
| width="33%" |
<center>difficile</center>
| width="33%" |
<center>forte</center>
|}

=== Capteurs ===

On peut imaginer différents types de capteurs :

* Accéléromètre

* Gyroscope

* Pression atmosphérique et altitude

* Température

* GPS

=== Mémoire ===

Le système doit être autonome et donc conserver un minimum de mesures pour les cas où la connexion est impossible. La mémoire doit être dimensionnée en fonction du nombre de capteurs, l’intervalle d’acquisition et le temps maximum avant connexion au système centralisé.

=== Protocole de communication ===

Un protocole de communication : dans un premier temps, nous nous concentrons sur le protocole BLE (Bluetooth Low Energie). Ce protocole étant standardisé, il nous permettra de recueillir de la documentation et réaliser des tests de consommation rapides.

== Planning prévisionnel ==

[[Fichier:P32Gant.PNG]]

==Suivi de l'avancement du Projet==
===Semaine 1 (28/09/2015)===

* Rencontre avec Monsieur Boe et Monsieur Giraud

* Présentation du projet

* Recherche documentaire

* Etablissement du cahier des charges

===Semaine 2 (05/10/2015)===

Recherche documentaire sur la consommation estimée des différents éléments.

{| class="wikitable centre" width="80%"
|+
|-
! scope=col | '''Contrôleur'''
! scope=col | Consommation Active
! scope=col | Consommation Inactive
! scope=col | Prix
|-
| width="33%" |
<center>Arduino Pro Mini 328 </center>
| width="34%" |
<center> 7mA (1 capteur)</center>
| width="33%" |
<center>4.5µA</center>
| width="33%" |
<center>Disponible</center>
|-
| width="33%" |
<center>STM32L4 Series (STM32L476JE)</center>
| width="34%" |
<center> 100 μA/MHz</center>
| width="33%" |
<center>120 nA</center>
| width="33%" |
<center>$5</center>
|-
| width="33%" |
<center>Raspberry</center>
| width="34%" |
<center> 200mA </center>
| width="33%" |
<center>200mA</center>
| width="33%" |
<center>Disponible</center>
|}

{| class="wikitable centre" width="80%"
|+
|-
! scope=col | '''Module BLE'''
! scope=col | Consommation
! scope=col | Options d'alimentation
! scope=col | Prix
|-
| width="33%" |
<center>BLE Mini</center>
| width="34%" |
<center> 15 mA </center>
| width="33%" |
<center>3.4V à 11V VIN / 5V USB / Coin Cell Battery (2025 or 2032) / 3.7V Li-ion Battery</center>
| width="33%" |
<center>$17</center>
|}

* <s> Le système Mini Arduino/ BLE Mini me semble être un bon compromis entre facilité d’intégration, consommation d'énergie et miniaturisation du système.</s> (Choix à discuter à la réunion du Merdredi 07/10)
* Choix du module RFduino

{| class="wikitable centre" width="80%"
|+
|-
! scope=col | '''Capteurs'''
! scope=col | Modèle
! scope=col | Alimentation min/max
! scope=col | Prix
|-
| width="33%" |
<center>Température</center>
| width="34%" |
<center> TMP36GT9Z </center>
| width="33%" |
<center>2.7V/5.5V</center>
| width="33%" |
<center>1,46 €</center>
|-
| width="33%" |
<center>Accéléromètre</center>
| width="34%" |
<center> ADXL345BCCZ </center>
| width="33%" |
<center>2V/3.6V</center>
| width="33%" |
<center>5,54 €</center>
|-
| width="33%" |
<center>Gyroscope+Accéléromètre</center>
| width="34%" |
<center> MPU-6050</center>
| width="33%" |
<center>2.5V/3.6V</center>
| width="33%" |
<center>15,73 €</center>
|-
| width="33%" |
<center>Pression atmosphérique / Altitude</center>
| width="34%" |
<center> MPL3115A2 </center>
| width="33%" |
<center>1.95V/3.6V</center>
| width="33%" |
<center>2,65 €</center>
|}

* Pour minimiser les pertes on cherche a travailler avec une tension d'alimentation la plus faible possible. Je propose de travailler avec une tension d'alimentation de 3,3V (Validé à discuter à la réunion du Merdredi 07/10)

* Le système de récupération d'énergie fonctionnant sur la base d'un mouvement, j'ai choisi l'ensemble des capteur ci dessus qui me semble être adapté à l'intégration dans un système en mouvement. (Validé à discuter à la réunion du Merdredi 07/10)

* Récupération des modules RFduino, prise en main

===Semaine 3 (12/10/2015)===

* Installation des librairies

* Visualisation d'exemples

* Tests d'implantation du code source du projet P14: Aimant intelligent de la session IMA4: 2014/2015

* Optimisation du code pour la réduction de la consommation d'énergie

* Recherches sur d'autres composants dans l'optique d'une consommation toujours plus faible

{| class="wikitable centre" width="80%"
|+
|-
! scope=col | '''Capteurs'''
! scope=col | Modèle
! scope=col | Alimentation min/max
! scope=col | Prix
! scope=col | Consommation (typ/max)
|-
| width="33%" |
<center>Température</center>
| width="34%" |
<center> STLM20W87F </center>
| width="33%" |
<center>2.4V/5.5V</center>
| width="33%" |
<center> 0,775 € </center>
| width="33%" |
<center> 4.8 μA/8.0 μA </center>
|}

'''Calcul théorique de la consommation énergétique du module BLE + RFD22301'''

Mode "endormi" : ARM CPU Running Current + Output standard drive current = 4 + 0.5 = 4.5mA

Mode "acquisition": ARM CPU Running Current + Output high drive current = 5 + 4 = 9mA

Mode "transmission" : ARM CPU Running Current + Transmit Current + Output standard drive current = 4 + 0.5 + 12 = 16.5mA

http://www.rfduino.com/wp-content/uploads/2014/03/RFD22301.Data_.Sheet_.11.24.13_11.38PM.pdf

'''Code possible du mode "endormi"'''

pinMode(5, INPUT);
RFduino_pinWake(5, HIGH);

RFduino_ULPDelay(INFINITE);
if (RFduino_pinWoke(5))
{
state = ! state;
RFduinoGZLL.sendToHost(state);
}

http://forum.rfduino.com/index.php?topic=385.0

===Semaine 4 (19/10/2015)===

* Réunion du 21/10

* Réalisation de tests

* Ajustement du nombre de capteurs : dans un premier temps on utilisera le capteur de température puis l'accéléromètre

* Discussion sur le bac de test et méthodes de test : résistance de visualisation, chronométrage du temps de transmission, vitesse du processeur

* Réalisation des premiers relevés

===Semaine 5 (26/10/2015)===

* Recherche bibliographique sur les modes d'endormissement du module RFduino

* Essais de codes utilisant un mode d'endormissement plus profond

* Réalisation de graphique de l'énergie utilisée par le module lors de la transmission d'un message par le module BLE.

* Recherches sur des méthodes de programmation pour la diminution de la vitesse processeur

[[Fichier:P32Montage.jpg|250px|thumb|left|'''Montage de test''']]
[[Fichier:P32resultats.jpg|250px|thumb|center|'''Visualisation du courant consommé lors d'envoi toutes les 10ms''']]

* On visualise à l'oscilloscope des pic d'envoi et des pic d'avertissement de la balise BLE, on peut ainsi déduire la puissance nécessaire de chaque action

===Semaine 6 (02/11/2015)===

* Test de diminution de la vitesse processeur

* Réalisation de graphique démontrant l'impact de la réduction de la vitesse processeur sur l'énergie consommée et déduction d'une vitesse optimale pour notre application

* Réunion du 4/11

Définition d'objectifs : Création d'un fichier excel permettant de caractériser les coûts en énergies de chaque étapes de fonctionnement du système.

* Création d'un environnement de test "normé" ( Pour éviter les variations de mesures on réalise un banc et on applique les mêmes conditions de test pour chaque essai)

* Recherche bibliographique sur la norme BLE : recherche du temps maximum entre deux "avertissements" de la balise BLE

===Semaine 7 (09/11/2015)===
* Explication du principe de communication BLE pour l'exploitation des résultats

[[Fichier:Freq.PNG]]

Nous nous intéressons dans notre projet à "l'observateur". Cet objet peut avoir trois états : stand-by, advertising et en communication.

[[Fichier:Brod2.png]]

Dans le mode "Advertising" le système peut :

- Avertir le système récepteur de la proximité d'un capteur

- Avertir de la présence à un appareil souhaitant ce connecter

- Ce reconnecter de façon asynchrone

===Semaine 8 (16/11/2015)===

Analyse en détail d'une trame BLE

[[Fichier:Com.PNG]]

On constate que pendant la durée de la trame il y a un échange entre les deux objets appairé. On s’intéresse ici uniquement aux actions "Slave Tx". Le but étant d'identifier la durée et le courant consommé par ces actions pour obtenir des valeurs en joules.

[[Fichier:SchemaCom.PNG]]

On constate donc deux phases :

- Advertising event

- Connexion event

Nous allons essayer de retrouver et quantifié l'énergie consommé dans ces deux phases.

===Semaine 9 (23/11/2015)===

Lors de cette semaine nous avons effectué des tests en respectant une procédure de test précise. En effet les valeurs des courants que nous relevons sont très petites aussi chaque variation du montage est susceptible de perturber les valeurs.

[[Fichier:P32Conne.jpg|250px|thumb|left|'''Phase connexion''']]

[[Fichier:Avertissement.jpg|250px|thumb|center|'''Phase Advertising''']]

===Semaine 10 (30/11/2015)===

- On cherche a diminuer légèrement la consommation par des modifications logiciel :

Réduction de la puissance de la radio BLE : Diminution de la portée

Augmentation de la fréquence d'advertising : tant que la fréquence d'advetising est inférieure a cette de relevé des capteurs on s'assure que la donnée envoyée est toujours mise à jour.

[[Fichier:Pwl20-envoi.jpg|250px|thumb|left|'''Avec modification logiciel''']]

[[Fichier:Sans-pwlvl.jpg|250px|thumb|center|'''Sans modification logiciel''']]

- On concentre nos résultats dans un tableau récapitulatif en vue du dimensionnement de la batterie du système

[[Fichier:P32tbresul.PNG]]

===Semaine 11 (07/12/2015)===

Tests d'intégration de plusieurs capteur et observations des modification de la consommation des ADC et de la durée/consommation de la transmission.

Réunion de vérification des tests.

Mise en évidence de la dualité consommation d'énergie - Temps de réponse du système

En effet chaque "Advertisement" consomme une quantité d'énergie nous pouvons gérer l'espacement entre ceux-ci mais plus ce temps serra élevé plus il faudra de temps pour ce connecter à ce périphérique.

* Rédaction d'un rapport de test

* Rédaction du rapport de pré soutenance

===Semaine 12 (14/12/2015)===

* Recherches de solutions pour l'amélioration du modèle
* Recherches Matlab pour effectuer une analyse statistique d’avènements aléatoires sur la liaison

===Semaine 13 (04/01/2016)===

*Amélioration du modèle

L’amélioration du modèle est réalisée en tenant compte des facteurs influent sur la qualité de la transmission.

* Utilisation d'un picoscope : appareil permettant l’acquisition sur ordinateur de plusieurs formes d'ondes.
Ainsi grâce a un pico scope utilisé à l’IRCICA j’ai pu relever de nombreux échantillons nécessaire a une étude statistique des surcoûts en énergie.

[[Fichier:Montagemulti.jpg|250px|thumb|left|'''Montage multi récepteur''']]

===Semaine 14 (11/01/2016)===

* Compilation des résultats

* Exploitation Matlab

[[Fichier:Emistbrecap.PNG]]

===Semaine 15 (18/01/2016)===

Principe de fonctionnement du récupérateur d’énergie

Le récupérateur d’énergie fonctionne grâce à un patch piezo. Ce patch est capable de produire un courent à partir de la vélocité d’une impulsion suivent la formule :

[[Fichier:Equapiezo.PNG]]

[[Fichier:Modelepizo.PNG|250px|thumb|left|'''Modèle simplifié du patch piezo''']]

Pour récupérer de l’énergie il est couplé au système suivent :

[[Fichier:montagepiezo.PNG]]

La puissance du système est définie par :

P=V*im

L’énergie s’exprime alors :

[[Fichier:Equaenergie.PNG]]

L’énergie produite par le système est donc dépendante de la tension d’alimentation V de la constante électromécanique N et du choc produit sur le patch piezo.
Une impulsion sur le capteur piezo est de la forme :

La dérivée par rapport au temps de cette impulsion est donc de la forme :

Il est donc important de « fenêtrer » la tension pour ne récupérer que la partie positive.
Ce fenêtrage ainsi que la fréquence de commutation du hacheur est assurée par un microcontrôleur.

Dans la suite de notre étude nous ne tiendrons pas compte de la consommation de celui-ci.

===Semaine 16 (25/01/2016)===

* Réflexions sur le prototypage

* Présentation du récupérateur

* Mise en place du banc de test

* Premiers relevés

[[Fichier:Montagepiezo.jpg|250px|thumb|left|'''Montage piezo''']]
[[Fichier:Patchpiezo.jpg|250px|thumb|center|'''Patch piezo''']]

===Semaine 17 (01/02/2016)===

Test de la quantité d’énergie récupérée par un patch piezo

Méthodologie :

Channel rouge : Tension aux bornes du patch piezo. Ici on observe une fenêtre de tension de 4,5ms imposée par le microcontrôleur.

Channel vert : Tension aux bornes de la capacité C1 de 220nF
[[Fichier:Diffpot.png|250px|thumb|center]]

On constate qu’un choc sur le patch piezo produit une énergie suivent la formule, E = V * N * Δw
N étant une constante électromécanique, on va faire varier V pour évaluer le gain en énergie. Cependant Δw est généré par un choc d’un stylo sur le patch il n’est donc pas uniforme.
Nous utilisons donc une méthode statistique qui consiste à retirer deux extrémum et faire la moyenne de 10 mesures.

Nous obtenons la courbe suivante :

On constate que la courbe n’est pas linéaire comme l’aurai laissé supposer la formule. En effet jusqu’à 30V elle est linéaire croissante suivent l’équation :

Puis après 30V elle devient quadratique décroissante suivent la formule :

En effet la formule E = V * N * Δw néglige les pertes. Celles-ci deviennent plus importante a chaque augmentation de la tension d’alimentation.

On obtient donc un point de fonctionnement optimal a 30V pour notre système. Ce qui impose que notre système soit équipé d’une source de tension en conséquence.

===Semaine 18 (08/02/2016)===
===Semaine 19 (15/02/2016)===
===Semaine 20 (22/02/2016)===

== Annexes ==

Consommation du STM32L4 Series : http://www.st.com/web/en/catalog/mmc/FM141/SC1169/SS1580?sc=stm32l4

Réduction de la consommation de l'Arduino : http://www.home-automation-community.com/arduino-low-power-how-to-run-atmega328p-for-a-year-on-coin-cell-battery/

Consommation Raspberry : https://www.raspberrypi.org/help/faqs/

Module BLE : http://redbearlab.com/blemini/

Accéléromètre : http://fr.farnell.com/analog-devices/adxl345bccz/accelerometre-3-axes-14lga/dp/1853935

Capteur température : http://fr.farnell.com/analog-devices/tmp36gt9z/capteur-temp-to-92-3/dp/1438760?ost=TMP36GT9Z
ou http://fr.farnell.com/stmicroelectronics/stlm20w87f/capteur-de-temperature-analog/dp/1391131

Accéléromètre + Gyroscope : http://fr.farnell.com/invensense/mpu-6050/gyroscope-accelero-6-axes-i2c/dp/1864742

Altimètre : http://fr.farnell.com/freescale-semiconductor/mpl3115a2/pressure-sensor-20-110kpa-8lga/dp/2009084?ost=MPL3115A2&categoryId=700000004367

Explications norme BLE : chapters.comsoc.org/vancouver/BTLER3.pdf

http://www.argenox.com/bluetooth-low-energy-ble-v4-0-development/library/a-ble-advertising-primer/

----

Fichiers MATLAB

[[Fichier:Recuperation.zip]]

[[Fichier:Recuperation3.zip]]

== Rapport de Mi-projet ==

[[Fichier:CR_Miprojet_Sultana.pdf‎ ]]

Fichier:Recuperation3.zip

2016-02-11T10:59:36Z

Qsultana : P32 : Fichiers Matlab récupération

P32 : Fichiers Matlab récupération

P32 Récupération d'énergie pour balise BLE

2016-02-10T17:10:24Z

Qsultana : /* Semaine 12 (14/12/2015) */

== Objectif ==

Mon projet consiste à réaliser un système électronique autonome, composé de différents capteurs et capable de recueillir et de transmettre les données mémorisées vers un système centralisé.

== Etude préalable ==

L’énergie est le point de difficulté dans la réalisation de ce projet. Chaque élément devra être choisi non seulement pour ses performances mais également pour sa faible consommation.

== Organisation générale ==

Le système est organisé autour d’une source d’énergie, d’un contrôleur, de capteurs, de mémoire et d’un protocole de communication.

On cherche à minimiser l'énergie consommée par l'ensemble du système.

[[Fichier:P32Ensemble.PNG|250px|thumb|left|'''Architecture''']]

=== Chaine de l’énergie ===

L’énergie pour ce module autonome est constituée de quatre phases importantes :

[[Fichier:P32Energie.PNG]]

==== La récupération de l'énergie dans l'environnement ====

Il existe de nombreux moyens pour récupérer de l'énergie dans l'environnement. L'objectif est de trouver les sources les plus adaptées à l'environnement de l'application recherchée.

On peut citer:

* La récupération de l'énergie par différence de température

* Les panneaux photovoltaïques

* La récupération de l'énergie des ondes radio

* La Piézoélectricité

Dans ce projet nous utiliserons la piézoélectricité, le module de récupération ayant déjà fait partie d'une étude de IRCICA précédent le projet.

==== Le stockage de l’énergie ====

Le choix du système de stockage de l'énergie constitue une partie importante de la réalisation du système.
La problématique de cette partie sera de déterminer quel type de stockage nous utiliserons : batterie, super-capacité ou un hybride et de les dimensionner.
Il faudra tenir compte des problèmes de décharge partielle influent sur la durée de vie du stockage.

==== Le management/mise en forme de l’énergie ====

L'objectif de cette partie est d'étudier la nécessité de la mise en place d'une régulation tout en préservant des contraintes de consommation très faibles.

==== L'utilisation de l'énergie mise en forme ====

On cherche à minimiser l'énergie consommée par l'ensemble du système.

=== Contrôleur ===

Le microprocesseur : il existe différents types de microprocesseurs. L'objectif est de choisir un support capable de consommer un minimum d'énergie tout en conservant une taille minimale. Nous avons déjà utilisé dans d'autres projets des micro-contrôleurs de type Arduino et Raspberry pie. Ceux-ci ont pour avantage d’être prêts à l'emploi et faciles de prise en main. On peut s’orienter également vers un contrôleur ultra low power comme le STM32L4.

{| class="wikitable centre" width="80%"
|+
|-
! scope=col |
! scope=col | Consommation
! scope=col | Facilité de développement
! scope=col | Miniaturisation
|-
| width="33%" |
<center>Arduino</center>
| width="34%" |
<center>faible à très faible</center>
| width="33%" |
<center>bonne</center>
| width="33%" |
<center>faible</center>
|-
| width="33%" |
<center>Raspberry pi</center>
| width="34%" |
<center>importante</center>
| width="34%" |
<center>très bonne</center>
| width="34%" |
<center>très faible</center>
|-
| width="33%" |
<center>Ultra low power</center>
| width="34%" |
<center>très, très faible</center>
| width="33%" |
<center>difficile</center>
| width="33%" |
<center>forte</center>
|}

=== Capteurs ===

On peut imaginer différents types de capteurs :

* Accéléromètre

* Gyroscope

* Pression atmosphérique et altitude

* Température

* GPS

=== Mémoire ===

Le système doit être autonome et donc conserver un minimum de mesures pour les cas où la connexion est impossible. La mémoire doit être dimensionnée en fonction du nombre de capteurs, l’intervalle d’acquisition et le temps maximum avant connexion au système centralisé.

=== Protocole de communication ===

Un protocole de communication : dans un premier temps, nous nous concentrons sur le protocole BLE (Bluetooth Low Energie). Ce protocole étant standardisé, il nous permettra de recueillir de la documentation et réaliser des tests de consommation rapides.

== Planning prévisionnel ==

[[Fichier:P32Gant.PNG]]

==Suivi de l'avancement du Projet==
===Semaine 1 (28/09/2015)===

* Rencontre avec Monsieur Boe et Monsieur Giraud

* Présentation du projet

* Recherche documentaire

* Etablissement du cahier des charges

===Semaine 2 (05/10/2015)===

Recherche documentaire sur la consommation estimée des différents éléments.

{| class="wikitable centre" width="80%"
|+
|-
! scope=col | '''Contrôleur'''
! scope=col | Consommation Active
! scope=col | Consommation Inactive
! scope=col | Prix
|-
| width="33%" |
<center>Arduino Pro Mini 328 </center>
| width="34%" |
<center> 7mA (1 capteur)</center>
| width="33%" |
<center>4.5µA</center>
| width="33%" |
<center>Disponible</center>
|-
| width="33%" |
<center>STM32L4 Series (STM32L476JE)</center>
| width="34%" |
<center> 100 μA/MHz</center>
| width="33%" |
<center>120 nA</center>
| width="33%" |
<center>$5</center>
|-
| width="33%" |
<center>Raspberry</center>
| width="34%" |
<center> 200mA </center>
| width="33%" |
<center>200mA</center>
| width="33%" |
<center>Disponible</center>
|}

{| class="wikitable centre" width="80%"
|+
|-
! scope=col | '''Module BLE'''
! scope=col | Consommation
! scope=col | Options d'alimentation
! scope=col | Prix
|-
| width="33%" |
<center>BLE Mini</center>
| width="34%" |
<center> 15 mA </center>
| width="33%" |
<center>3.4V à 11V VIN / 5V USB / Coin Cell Battery (2025 or 2032) / 3.7V Li-ion Battery</center>
| width="33%" |
<center>$17</center>
|}

* <s> Le système Mini Arduino/ BLE Mini me semble être un bon compromis entre facilité d’intégration, consommation d'énergie et miniaturisation du système.</s> (Choix à discuter à la réunion du Merdredi 07/10)
* Choix du module RFduino

{| class="wikitable centre" width="80%"
|+
|-
! scope=col | '''Capteurs'''
! scope=col | Modèle
! scope=col | Alimentation min/max
! scope=col | Prix
|-
| width="33%" |
<center>Température</center>
| width="34%" |
<center> TMP36GT9Z </center>
| width="33%" |
<center>2.7V/5.5V</center>
| width="33%" |
<center>1,46 €</center>
|-
| width="33%" |
<center>Accéléromètre</center>
| width="34%" |
<center> ADXL345BCCZ </center>
| width="33%" |
<center>2V/3.6V</center>
| width="33%" |
<center>5,54 €</center>
|-
| width="33%" |
<center>Gyroscope+Accéléromètre</center>
| width="34%" |
<center> MPU-6050</center>
| width="33%" |
<center>2.5V/3.6V</center>
| width="33%" |
<center>15,73 €</center>
|-
| width="33%" |
<center>Pression atmosphérique / Altitude</center>
| width="34%" |
<center> MPL3115A2 </center>
| width="33%" |
<center>1.95V/3.6V</center>
| width="33%" |
<center>2,65 €</center>
|}

* Pour minimiser les pertes on cherche a travailler avec une tension d'alimentation la plus faible possible. Je propose de travailler avec une tension d'alimentation de 3,3V (Validé à discuter à la réunion du Merdredi 07/10)

* Le système de récupération d'énergie fonctionnant sur la base d'un mouvement, j'ai choisi l'ensemble des capteur ci dessus qui me semble être adapté à l'intégration dans un système en mouvement. (Validé à discuter à la réunion du Merdredi 07/10)

* Récupération des modules RFduino, prise en main

===Semaine 3 (12/10/2015)===

* Installation des librairies

* Visualisation d'exemples

* Tests d'implantation du code source du projet P14: Aimant intelligent de la session IMA4: 2014/2015

* Optimisation du code pour la réduction de la consommation d'énergie

* Recherches sur d'autres composants dans l'optique d'une consommation toujours plus faible

{| class="wikitable centre" width="80%"
|+
|-
! scope=col | '''Capteurs'''
! scope=col | Modèle
! scope=col | Alimentation min/max
! scope=col | Prix
! scope=col | Consommation (typ/max)
|-
| width="33%" |
<center>Température</center>
| width="34%" |
<center> STLM20W87F </center>
| width="33%" |
<center>2.4V/5.5V</center>
| width="33%" |
<center> 0,775 € </center>
| width="33%" |
<center> 4.8 μA/8.0 μA </center>
|}

'''Calcul théorique de la consommation énergétique du module BLE + RFD22301'''

Mode "endormi" : ARM CPU Running Current + Output standard drive current = 4 + 0.5 = 4.5mA

Mode "acquisition": ARM CPU Running Current + Output high drive current = 5 + 4 = 9mA

Mode "transmission" : ARM CPU Running Current + Transmit Current + Output standard drive current = 4 + 0.5 + 12 = 16.5mA

http://www.rfduino.com/wp-content/uploads/2014/03/RFD22301.Data_.Sheet_.11.24.13_11.38PM.pdf

'''Code possible du mode "endormi"'''

pinMode(5, INPUT);
RFduino_pinWake(5, HIGH);

RFduino_ULPDelay(INFINITE);
if (RFduino_pinWoke(5))
{
state = ! state;
RFduinoGZLL.sendToHost(state);
}

http://forum.rfduino.com/index.php?topic=385.0

===Semaine 4 (19/10/2015)===

* Réunion du 21/10

* Réalisation de tests

* Ajustement du nombre de capteurs : dans un premier temps on utilisera le capteur de température puis l'accéléromètre

* Discussion sur le bac de test et méthodes de test : résistance de visualisation, chronométrage du temps de transmission, vitesse du processeur

* Réalisation des premiers relevés

===Semaine 5 (26/10/2015)===

* Recherche bibliographique sur les modes d'endormissement du module RFduino

* Essais de codes utilisant un mode d'endormissement plus profond

* Réalisation de graphique de l'énergie utilisée par le module lors de la transmission d'un message par le module BLE.

* Recherches sur des méthodes de programmation pour la diminution de la vitesse processeur

[[Fichier:P32Montage.jpg|250px|thumb|left|'''Montage de test''']]
[[Fichier:P32resultats.jpg|250px|thumb|center|'''Visualisation du courant consommé lors d'envoi toutes les 10ms''']]

* On visualise à l'oscilloscope des pic d'envoi et des pic d'avertissement de la balise BLE, on peut ainsi déduire la puissance nécessaire de chaque action

===Semaine 6 (02/11/2015)===

* Test de diminution de la vitesse processeur

* Réalisation de graphique démontrant l'impact de la réduction de la vitesse processeur sur l'énergie consommée et déduction d'une vitesse optimale pour notre application

* Réunion du 4/11

Définition d'objectifs : Création d'un fichier excel permettant de caractériser les coûts en énergies de chaque étapes de fonctionnement du système.

* Création d'un environnement de test "normé" ( Pour éviter les variations de mesures on réalise un banc et on applique les mêmes conditions de test pour chaque essai)

* Recherche bibliographique sur la norme BLE : recherche du temps maximum entre deux "avertissements" de la balise BLE

===Semaine 7 (09/11/2015)===
* Explication du principe de communication BLE pour l'exploitation des résultats

[[Fichier:Freq.PNG]]

Nous nous intéressons dans notre projet à "l'observateur". Cet objet peut avoir trois états : stand-by, advertising et en communication.

[[Fichier:Brod2.png]]

Dans le mode "Advertising" le système peut :

- Avertir le système récepteur de la proximité d'un capteur

- Avertir de la présence à un appareil souhaitant ce connecter

- Ce reconnecter de façon asynchrone

===Semaine 8 (16/11/2015)===

Analyse en détail d'une trame BLE

[[Fichier:Com.PNG]]

On constate que pendant la durée de la trame il y a un échange entre les deux objets appairé. On s’intéresse ici uniquement aux actions "Slave Tx". Le but étant d'identifier la durée et le courant consommé par ces actions pour obtenir des valeurs en joules.

[[Fichier:SchemaCom.PNG]]

On constate donc deux phases :

- Advertising event

- Connexion event

Nous allons essayer de retrouver et quantifié l'énergie consommé dans ces deux phases.

===Semaine 9 (23/11/2015)===

Lors de cette semaine nous avons effectué des tests en respectant une procédure de test précise. En effet les valeurs des courants que nous relevons sont très petites aussi chaque variation du montage est susceptible de perturber les valeurs.

[[Fichier:P32Conne.jpg|250px|thumb|left|'''Phase connexion''']]

[[Fichier:Avertissement.jpg|250px|thumb|center|'''Phase Advertising''']]

===Semaine 10 (30/11/2015)===

- On cherche a diminuer légèrement la consommation par des modifications logiciel :

Réduction de la puissance de la radio BLE : Diminution de la portée

Augmentation de la fréquence d'advertising : tant que la fréquence d'advetising est inférieure a cette de relevé des capteurs on s'assure que la donnée envoyée est toujours mise à jour.

[[Fichier:Pwl20-envoi.jpg|250px|thumb|left|'''Avec modification logiciel''']]

[[Fichier:Sans-pwlvl.jpg|250px|thumb|center|'''Sans modification logiciel''']]

- On concentre nos résultats dans un tableau récapitulatif en vue du dimensionnement de la batterie du système

[[Fichier:P32tbresul.PNG]]

===Semaine 11 (07/12/2015)===

Tests d'intégration de plusieurs capteur et observations des modification de la consommation des ADC et de la durée/consommation de la transmission.

Réunion de vérification des tests.

Mise en évidence de la dualité consommation d'énergie - Temps de réponse du système

En effet chaque "Advertisement" consomme une quantité d'énergie nous pouvons gérer l'espacement entre ceux-ci mais plus ce temps serra élevé plus il faudra de temps pour ce connecter à ce périphérique.

* Rédaction d'un rapport de test

* Rédaction du rapport de pré soutenance

===Semaine 12 (14/12/2015)===

* Recherches de solutions pour l'amélioration du modèle
* Recherches Matlab pour effectuer une analyse statistique d’avènements aléatoires sur la liaison

===Semaine 13 (04/01/2016)===

*Amélioration du modèle

L’amélioration du modèle est réalisée en tenant compte des facteurs influent sur la qualité de la transmission.

* Utilisation d'un picoscope : appareil permettant l’acquisition sur ordinateur de plusieurs formes d'ondes.
Ainsi grâce a un pico scope utilisé à l’IRCICA j’ai pu relever de nombreux échantillons nécessaire a une étude statistique des surcoûts en énergie.

[[Fichier:Montagemulti.jpg|250px|thumb|left|'''Montage multi récepteur''']]

===Semaine 14 (11/01/2016)===

* Compilation des résultats

* Exploitation Matlab

[[Fichier:Emistbrecap.PNG]]

===Semaine 15 (18/01/2016)===

Principe de fonctionnement du récupérateur d’énergie

Le récupérateur d’énergie fonctionne grâce à un patch piezo. Ce patch est capable de produire un courent à partir de la vélocité d’une impulsion suivent la formule :

[[Fichier:Equapiezo.PNG]]

[[Fichier:Modelepizo.PNG|250px|thumb|left|'''Modèle simplifié du patch piezo''']]

Pour récupérer de l’énergie il est couplé au système suivent :

[[Fichier:montagepiezo.PNG]]

La puissance du système est définie par :

P=V*im

L’énergie s’exprime alors :

[[Fichier:Equaenergie.PNG]]

L’énergie produite par le système est donc dépendante de la tension d’alimentation V de la constante électromécanique N et du choc produit sur le patch piezo.
Une impulsion sur le capteur piezo est de la forme :

La dérivée par rapport au temps de cette impulsion est donc de la forme :

Il est donc important de « fenêtrer » la tension pour ne récupérer que la partie positive.
Ce fenêtrage ainsi que la fréquence de commutation du hacheur est assurée par un microcontrôleur.

Dans la suite de notre étude nous ne tiendrons pas compte de la consommation de celui-ci.

===Semaine 16 (25/01/2016)===

* Réflexions sur le prototypage

* Présentation du récupérateur

* Mise en place du banc de test

* Premiers relevés

[[Fichier:Montagepiezo.jpg|250px|thumb|left|'''Montage piezo''']]
[[Fichier:Patchpiezo.jpg|250px|thumb|center|'''Patch piezo''']]

===Semaine 17 (01/02/2016)===

Test de la quantité d’énergie récupérée par un patch piezo

Méthodologie :

Channel rouge : Tension aux bornes du patch piezo. Ici on observe une fenêtre de tension de 4,5ms imposée par le microcontrôleur.

Channel vert : Tension aux bornes de la capacité C1 de 220nF
[[Fichier:Diffpot.png|250px|thumb|center]]

On constate qu’un choc sur le patch piezo produit une énergie suivent la formule, E = V * N * Δw
N étant une constante électromécanique, on va faire varier V pour évaluer le gain en énergie. Cependant Δw est généré par un choc d’un stylo sur le patch il n’est donc pas uniforme.
Nous utilisons donc une méthode statistique qui consiste à retirer deux extrémum et faire la moyenne de 10 mesures.

Nous obtenons la courbe suivante :

On constate que la courbe n’est pas linéaire comme l’aurai laissé supposer la formule. En effet jusqu’à 30V elle est linéaire croissante suivent l’équation :

Puis après 30V elle devient quadratique décroissante suivent la formule :

En effet la formule E = V * N * Δw néglige les pertes. Celles-ci deviennent plus importante a chaque augmentation de la tension d’alimentation.

On obtient donc un point de fonctionnement optimal a 30V pour notre système. Ce qui impose que notre système soit équipé d’une source de tension en conséquence.

===Semaine 18 (08/02/2016)===
===Semaine 19 (15/02/2016)===
===Semaine 20 (22/02/2016)===

== Annexes ==

Consommation du STM32L4 Series : http://www.st.com/web/en/catalog/mmc/FM141/SC1169/SS1580?sc=stm32l4

Réduction de la consommation de l'Arduino : http://www.home-automation-community.com/arduino-low-power-how-to-run-atmega328p-for-a-year-on-coin-cell-battery/

Consommation Raspberry : https://www.raspberrypi.org/help/faqs/

Module BLE : http://redbearlab.com/blemini/

Accéléromètre : http://fr.farnell.com/analog-devices/adxl345bccz/accelerometre-3-axes-14lga/dp/1853935

Capteur température : http://fr.farnell.com/analog-devices/tmp36gt9z/capteur-temp-to-92-3/dp/1438760?ost=TMP36GT9Z
ou http://fr.farnell.com/stmicroelectronics/stlm20w87f/capteur-de-temperature-analog/dp/1391131

Accéléromètre + Gyroscope : http://fr.farnell.com/invensense/mpu-6050/gyroscope-accelero-6-axes-i2c/dp/1864742

Altimètre : http://fr.farnell.com/freescale-semiconductor/mpl3115a2/pressure-sensor-20-110kpa-8lga/dp/2009084?ost=MPL3115A2&categoryId=700000004367

Explications norme BLE : chapters.comsoc.org/vancouver/BTLER3.pdf

http://www.argenox.com/bluetooth-low-energy-ble-v4-0-development/library/a-ble-advertising-primer/

----

Fichiers MATLAB

[[Fichier:Recuperation.zip]]

== Rapport de Mi-projet ==

[[Fichier:CR_Miprojet_Sultana.pdf‎ ]]

P32 Récupération d'énergie pour balise BLE

2016-02-10T17:08:39Z

Qsultana : /* Annexes */

== Objectif ==

Mon projet consiste à réaliser un système électronique autonome, composé de différents capteurs et capable de recueillir et de transmettre les données mémorisées vers un système centralisé.

== Etude préalable ==

L’énergie est le point de difficulté dans la réalisation de ce projet. Chaque élément devra être choisi non seulement pour ses performances mais également pour sa faible consommation.

== Organisation générale ==

Le système est organisé autour d’une source d’énergie, d’un contrôleur, de capteurs, de mémoire et d’un protocole de communication.

On cherche à minimiser l'énergie consommée par l'ensemble du système.

[[Fichier:P32Ensemble.PNG|250px|thumb|left|'''Architecture''']]

=== Chaine de l’énergie ===

L’énergie pour ce module autonome est constituée de quatre phases importantes :

[[Fichier:P32Energie.PNG]]

==== La récupération de l'énergie dans l'environnement ====

Il existe de nombreux moyens pour récupérer de l'énergie dans l'environnement. L'objectif est de trouver les sources les plus adaptées à l'environnement de l'application recherchée.

On peut citer:

* La récupération de l'énergie par différence de température

* Les panneaux photovoltaïques

* La récupération de l'énergie des ondes radio

* La Piézoélectricité

Dans ce projet nous utiliserons la piézoélectricité, le module de récupération ayant déjà fait partie d'une étude de IRCICA précédent le projet.

==== Le stockage de l’énergie ====

Le choix du système de stockage de l'énergie constitue une partie importante de la réalisation du système.
La problématique de cette partie sera de déterminer quel type de stockage nous utiliserons : batterie, super-capacité ou un hybride et de les dimensionner.
Il faudra tenir compte des problèmes de décharge partielle influent sur la durée de vie du stockage.

==== Le management/mise en forme de l’énergie ====

L'objectif de cette partie est d'étudier la nécessité de la mise en place d'une régulation tout en préservant des contraintes de consommation très faibles.

==== L'utilisation de l'énergie mise en forme ====

On cherche à minimiser l'énergie consommée par l'ensemble du système.

=== Contrôleur ===

Le microprocesseur : il existe différents types de microprocesseurs. L'objectif est de choisir un support capable de consommer un minimum d'énergie tout en conservant une taille minimale. Nous avons déjà utilisé dans d'autres projets des micro-contrôleurs de type Arduino et Raspberry pie. Ceux-ci ont pour avantage d’être prêts à l'emploi et faciles de prise en main. On peut s’orienter également vers un contrôleur ultra low power comme le STM32L4.

{| class="wikitable centre" width="80%"
|+
|-
! scope=col |
! scope=col | Consommation
! scope=col | Facilité de développement
! scope=col | Miniaturisation
|-
| width="33%" |
<center>Arduino</center>
| width="34%" |
<center>faible à très faible</center>
| width="33%" |
<center>bonne</center>
| width="33%" |
<center>faible</center>
|-
| width="33%" |
<center>Raspberry pi</center>
| width="34%" |
<center>importante</center>
| width="34%" |
<center>très bonne</center>
| width="34%" |
<center>très faible</center>
|-
| width="33%" |
<center>Ultra low power</center>
| width="34%" |
<center>très, très faible</center>
| width="33%" |
<center>difficile</center>
| width="33%" |
<center>forte</center>
|}

=== Capteurs ===

On peut imaginer différents types de capteurs :

* Accéléromètre

* Gyroscope

* Pression atmosphérique et altitude

* Température

* GPS

=== Mémoire ===

Le système doit être autonome et donc conserver un minimum de mesures pour les cas où la connexion est impossible. La mémoire doit être dimensionnée en fonction du nombre de capteurs, l’intervalle d’acquisition et le temps maximum avant connexion au système centralisé.

=== Protocole de communication ===

Un protocole de communication : dans un premier temps, nous nous concentrons sur le protocole BLE (Bluetooth Low Energie). Ce protocole étant standardisé, il nous permettra de recueillir de la documentation et réaliser des tests de consommation rapides.

== Planning prévisionnel ==

[[Fichier:P32Gant.PNG]]

==Suivi de l'avancement du Projet==
===Semaine 1 (28/09/2015)===

* Rencontre avec Monsieur Boe et Monsieur Giraud

* Présentation du projet

* Recherche documentaire

* Etablissement du cahier des charges

===Semaine 2 (05/10/2015)===

Recherche documentaire sur la consommation estimée des différents éléments.

{| class="wikitable centre" width="80%"
|+
|-
! scope=col | '''Contrôleur'''
! scope=col | Consommation Active
! scope=col | Consommation Inactive
! scope=col | Prix
|-
| width="33%" |
<center>Arduino Pro Mini 328 </center>
| width="34%" |
<center> 7mA (1 capteur)</center>
| width="33%" |
<center>4.5µA</center>
| width="33%" |
<center>Disponible</center>
|-
| width="33%" |
<center>STM32L4 Series (STM32L476JE)</center>
| width="34%" |
<center> 100 μA/MHz</center>
| width="33%" |
<center>120 nA</center>
| width="33%" |
<center>$5</center>
|-
| width="33%" |
<center>Raspberry</center>
| width="34%" |
<center> 200mA </center>
| width="33%" |
<center>200mA</center>
| width="33%" |
<center>Disponible</center>
|}

{| class="wikitable centre" width="80%"
|+
|-
! scope=col | '''Module BLE'''
! scope=col | Consommation
! scope=col | Options d'alimentation
! scope=col | Prix
|-
| width="33%" |
<center>BLE Mini</center>
| width="34%" |
<center> 15 mA </center>
| width="33%" |
<center>3.4V à 11V VIN / 5V USB / Coin Cell Battery (2025 or 2032) / 3.7V Li-ion Battery</center>
| width="33%" |
<center>$17</center>
|}

* <s> Le système Mini Arduino/ BLE Mini me semble être un bon compromis entre facilité d’intégration, consommation d'énergie et miniaturisation du système.</s> (Choix à discuter à la réunion du Merdredi 07/10)
* Choix du module RFduino

{| class="wikitable centre" width="80%"
|+
|-
! scope=col | '''Capteurs'''
! scope=col | Modèle
! scope=col | Alimentation min/max
! scope=col | Prix
|-
| width="33%" |
<center>Température</center>
| width="34%" |
<center> TMP36GT9Z </center>
| width="33%" |
<center>2.7V/5.5V</center>
| width="33%" |
<center>1,46 €</center>
|-
| width="33%" |
<center>Accéléromètre</center>
| width="34%" |
<center> ADXL345BCCZ </center>
| width="33%" |
<center>2V/3.6V</center>
| width="33%" |
<center>5,54 €</center>
|-
| width="33%" |
<center>Gyroscope+Accéléromètre</center>
| width="34%" |
<center> MPU-6050</center>
| width="33%" |
<center>2.5V/3.6V</center>
| width="33%" |
<center>15,73 €</center>
|-
| width="33%" |
<center>Pression atmosphérique / Altitude</center>
| width="34%" |
<center> MPL3115A2 </center>
| width="33%" |
<center>1.95V/3.6V</center>
| width="33%" |
<center>2,65 €</center>
|}

* Pour minimiser les pertes on cherche a travailler avec une tension d'alimentation la plus faible possible. Je propose de travailler avec une tension d'alimentation de 3,3V (Validé à discuter à la réunion du Merdredi 07/10)

* Le système de récupération d'énergie fonctionnant sur la base d'un mouvement, j'ai choisi l'ensemble des capteur ci dessus qui me semble être adapté à l'intégration dans un système en mouvement. (Validé à discuter à la réunion du Merdredi 07/10)

* Récupération des modules RFduino, prise en main

===Semaine 3 (12/10/2015)===

* Installation des librairies

* Visualisation d'exemples

* Tests d'implantation du code source du projet P14: Aimant intelligent de la session IMA4: 2014/2015

* Optimisation du code pour la réduction de la consommation d'énergie

* Recherches sur d'autres composants dans l'optique d'une consommation toujours plus faible

{| class="wikitable centre" width="80%"
|+
|-
! scope=col | '''Capteurs'''
! scope=col | Modèle
! scope=col | Alimentation min/max
! scope=col | Prix
! scope=col | Consommation (typ/max)
|-
| width="33%" |
<center>Température</center>
| width="34%" |
<center> STLM20W87F </center>
| width="33%" |
<center>2.4V/5.5V</center>
| width="33%" |
<center> 0,775 € </center>
| width="33%" |
<center> 4.8 μA/8.0 μA </center>
|}

'''Calcul théorique de la consommation énergétique du module BLE + RFD22301'''

Mode "endormi" : ARM CPU Running Current + Output standard drive current = 4 + 0.5 = 4.5mA

Mode "acquisition": ARM CPU Running Current + Output high drive current = 5 + 4 = 9mA

Mode "transmission" : ARM CPU Running Current + Transmit Current + Output standard drive current = 4 + 0.5 + 12 = 16.5mA

http://www.rfduino.com/wp-content/uploads/2014/03/RFD22301.Data_.Sheet_.11.24.13_11.38PM.pdf

'''Code possible du mode "endormi"'''

pinMode(5, INPUT);
RFduino_pinWake(5, HIGH);

RFduino_ULPDelay(INFINITE);
if (RFduino_pinWoke(5))
{
state = ! state;
RFduinoGZLL.sendToHost(state);
}

http://forum.rfduino.com/index.php?topic=385.0

===Semaine 4 (19/10/2015)===

* Réunion du 21/10

* Réalisation de tests

* Ajustement du nombre de capteurs : dans un premier temps on utilisera le capteur de température puis l'accéléromètre

* Discussion sur le bac de test et méthodes de test : résistance de visualisation, chronométrage du temps de transmission, vitesse du processeur

* Réalisation des premiers relevés

===Semaine 5 (26/10/2015)===

* Recherche bibliographique sur les modes d'endormissement du module RFduino

* Essais de codes utilisant un mode d'endormissement plus profond

* Réalisation de graphique de l'énergie utilisée par le module lors de la transmission d'un message par le module BLE.

* Recherches sur des méthodes de programmation pour la diminution de la vitesse processeur

[[Fichier:P32Montage.jpg|250px|thumb|left|'''Montage de test''']]
[[Fichier:P32resultats.jpg|250px|thumb|center|'''Visualisation du courant consommé lors d'envoi toutes les 10ms''']]

* On visualise à l'oscilloscope des pic d'envoi et des pic d'avertissement de la balise BLE, on peut ainsi déduire la puissance nécessaire de chaque action

===Semaine 6 (02/11/2015)===

* Test de diminution de la vitesse processeur

* Réalisation de graphique démontrant l'impact de la réduction de la vitesse processeur sur l'énergie consommée et déduction d'une vitesse optimale pour notre application

* Réunion du 4/11

Définition d'objectifs : Création d'un fichier excel permettant de caractériser les coûts en énergies de chaque étapes de fonctionnement du système.

* Création d'un environnement de test "normé" ( Pour éviter les variations de mesures on réalise un banc et on applique les mêmes conditions de test pour chaque essai)

* Recherche bibliographique sur la norme BLE : recherche du temps maximum entre deux "avertissements" de la balise BLE

===Semaine 7 (09/11/2015)===
* Explication du principe de communication BLE pour l'exploitation des résultats

[[Fichier:Freq.PNG]]

Nous nous intéressons dans notre projet à "l'observateur". Cet objet peut avoir trois états : stand-by, advertising et en communication.

[[Fichier:Brod2.png]]

Dans le mode "Advertising" le système peut :

- Avertir le système récepteur de la proximité d'un capteur

- Avertir de la présence à un appareil souhaitant ce connecter

- Ce reconnecter de façon asynchrone

===Semaine 8 (16/11/2015)===

Analyse en détail d'une trame BLE

[[Fichier:Com.PNG]]

On constate que pendant la durée de la trame il y a un échange entre les deux objets appairé. On s’intéresse ici uniquement aux actions "Slave Tx". Le but étant d'identifier la durée et le courant consommé par ces actions pour obtenir des valeurs en joules.

[[Fichier:SchemaCom.PNG]]

On constate donc deux phases :

- Advertising event

- Connexion event

Nous allons essayer de retrouver et quantifié l'énergie consommé dans ces deux phases.

===Semaine 9 (23/11/2015)===

Lors de cette semaine nous avons effectué des tests en respectant une procédure de test précise. En effet les valeurs des courants que nous relevons sont très petites aussi chaque variation du montage est susceptible de perturber les valeurs.

[[Fichier:P32Conne.jpg|250px|thumb|left|'''Phase connexion''']]

[[Fichier:Avertissement.jpg|250px|thumb|center|'''Phase Advertising''']]

===Semaine 10 (30/11/2015)===

- On cherche a diminuer légèrement la consommation par des modifications logiciel :

Réduction de la puissance de la radio BLE : Diminution de la portée

Augmentation de la fréquence d'advertising : tant que la fréquence d'advetising est inférieure a cette de relevé des capteurs on s'assure que la donnée envoyée est toujours mise à jour.

[[Fichier:Pwl20-envoi.jpg|250px|thumb|left|'''Avec modification logiciel''']]

[[Fichier:Sans-pwlvl.jpg|250px|thumb|center|'''Sans modification logiciel''']]

- On concentre nos résultats dans un tableau récapitulatif en vue du dimensionnement de la batterie du système

[[Fichier:P32tbresul.PNG]]

===Semaine 11 (07/12/2015)===

Tests d'intégration de plusieurs capteur et observations des modification de la consommation des ADC et de la durée/consommation de la transmission.

Réunion de vérification des tests.

Mise en évidence de la dualité consommation d'énergie - Temps de réponse du système

En effet chaque "Advertisement" consomme une quantité d'énergie nous pouvons gérer l'espacement entre ceux-ci mais plus ce temps serra élevé plus il faudra de temps pour ce connecter à ce périphérique.

* Rédaction d'un rapport de test

* Rédaction du rapport de pré soutenance

===Semaine 12 (14/12/2015)===
===Semaine 13 (04/01/2016)===

*Amélioration du modèle

L’amélioration du modèle est réalisée en tenant compte des facteurs influent sur la qualité de la transmission.

* Utilisation d'un picoscope : appareil permettant l’acquisition sur ordinateur de plusieurs formes d'ondes.
Ainsi grâce a un pico scope utilisé à l’IRCICA j’ai pu relever de nombreux échantillons nécessaire a une étude statistique des surcoûts en énergie.

[[Fichier:Montagemulti.jpg|250px|thumb|left|'''Montage multi récepteur''']]

===Semaine 14 (11/01/2016)===

* Compilation des résultats

* Exploitation Matlab

[[Fichier:Emistbrecap.PNG]]

===Semaine 15 (18/01/2016)===

Principe de fonctionnement du récupérateur d’énergie

Le récupérateur d’énergie fonctionne grâce à un patch piezo. Ce patch est capable de produire un courent à partir de la vélocité d’une impulsion suivent la formule :

[[Fichier:Equapiezo.PNG]]

[[Fichier:Modelepizo.PNG|250px|thumb|left|'''Modèle simplifié du patch piezo''']]

Pour récupérer de l’énergie il est couplé au système suivent :

[[Fichier:montagepiezo.PNG]]

La puissance du système est définie par :

P=V*im

L’énergie s’exprime alors :

[[Fichier:Equaenergie.PNG]]

L’énergie produite par le système est donc dépendante de la tension d’alimentation V de la constante électromécanique N et du choc produit sur le patch piezo.
Une impulsion sur le capteur piezo est de la forme :

La dérivée par rapport au temps de cette impulsion est donc de la forme :

Il est donc important de « fenêtrer » la tension pour ne récupérer que la partie positive.
Ce fenêtrage ainsi que la fréquence de commutation du hacheur est assurée par un microcontrôleur.

Dans la suite de notre étude nous ne tiendrons pas compte de la consommation de celui-ci.

===Semaine 16 (25/01/2016)===

* Réflexions sur le prototypage

* Présentation du récupérateur

* Mise en place du banc de test

* Premiers relevés

[[Fichier:Montagepiezo.jpg|250px|thumb|left|'''Montage piezo''']]
[[Fichier:Patchpiezo.jpg|250px|thumb|center|'''Patch piezo''']]

===Semaine 17 (01/02/2016)===

Test de la quantité d’énergie récupérée par un patch piezo

Méthodologie :

Channel rouge : Tension aux bornes du patch piezo. Ici on observe une fenêtre de tension de 4,5ms imposée par le microcontrôleur.

Channel vert : Tension aux bornes de la capacité C1 de 220nF
[[Fichier:Diffpot.png|250px|thumb|center]]

On constate qu’un choc sur le patch piezo produit une énergie suivent la formule, E = V * N * Δw
N étant une constante électromécanique, on va faire varier V pour évaluer le gain en énergie. Cependant Δw est généré par un choc d’un stylo sur le patch il n’est donc pas uniforme.
Nous utilisons donc une méthode statistique qui consiste à retirer deux extrémum et faire la moyenne de 10 mesures.

Nous obtenons la courbe suivante :

On constate que la courbe n’est pas linéaire comme l’aurai laissé supposer la formule. En effet jusqu’à 30V elle est linéaire croissante suivent l’équation :

Puis après 30V elle devient quadratique décroissante suivent la formule :

En effet la formule E = V * N * Δw néglige les pertes. Celles-ci deviennent plus importante a chaque augmentation de la tension d’alimentation.

On obtient donc un point de fonctionnement optimal a 30V pour notre système. Ce qui impose que notre système soit équipé d’une source de tension en conséquence.

===Semaine 18 (08/02/2016)===
===Semaine 19 (15/02/2016)===
===Semaine 20 (22/02/2016)===

== Annexes ==

Consommation du STM32L4 Series : http://www.st.com/web/en/catalog/mmc/FM141/SC1169/SS1580?sc=stm32l4

Réduction de la consommation de l'Arduino : http://www.home-automation-community.com/arduino-low-power-how-to-run-atmega328p-for-a-year-on-coin-cell-battery/

Consommation Raspberry : https://www.raspberrypi.org/help/faqs/

Module BLE : http://redbearlab.com/blemini/

Accéléromètre : http://fr.farnell.com/analog-devices/adxl345bccz/accelerometre-3-axes-14lga/dp/1853935

Capteur température : http://fr.farnell.com/analog-devices/tmp36gt9z/capteur-temp-to-92-3/dp/1438760?ost=TMP36GT9Z
ou http://fr.farnell.com/stmicroelectronics/stlm20w87f/capteur-de-temperature-analog/dp/1391131

Accéléromètre + Gyroscope : http://fr.farnell.com/invensense/mpu-6050/gyroscope-accelero-6-axes-i2c/dp/1864742

Altimètre : http://fr.farnell.com/freescale-semiconductor/mpl3115a2/pressure-sensor-20-110kpa-8lga/dp/2009084?ost=MPL3115A2&categoryId=700000004367

Explications norme BLE : chapters.comsoc.org/vancouver/BTLER3.pdf

http://www.argenox.com/bluetooth-low-energy-ble-v4-0-development/library/a-ble-advertising-primer/

----

Fichiers MATLAB

[[Fichier:Recuperation.zip]]

== Rapport de Mi-projet ==

[[Fichier:CR_Miprojet_Sultana.pdf‎ ]]

Fichier:Recuperation.zip

2016-02-10T17:08:19Z

Qsultana : P32 : Fichiers MATLAB récupération d'énergie piezo

P32 : Fichiers MATLAB récupération d'énergie piezo

P32 Récupération d'énergie pour balise BLE

2016-02-10T15:58:49Z

Qsultana : /* Semaine 16 (25/01/2016) */

== Objectif ==

Mon projet consiste à réaliser un système électronique autonome, composé de différents capteurs et capable de recueillir et de transmettre les données mémorisées vers un système centralisé.

== Etude préalable ==

L’énergie est le point de difficulté dans la réalisation de ce projet. Chaque élément devra être choisi non seulement pour ses performances mais également pour sa faible consommation.

== Organisation générale ==

Le système est organisé autour d’une source d’énergie, d’un contrôleur, de capteurs, de mémoire et d’un protocole de communication.

On cherche à minimiser l'énergie consommée par l'ensemble du système.

[[Fichier:P32Ensemble.PNG|250px|thumb|left|'''Architecture''']]

=== Chaine de l’énergie ===

L’énergie pour ce module autonome est constituée de quatre phases importantes :

[[Fichier:P32Energie.PNG]]

==== La récupération de l'énergie dans l'environnement ====

Il existe de nombreux moyens pour récupérer de l'énergie dans l'environnement. L'objectif est de trouver les sources les plus adaptées à l'environnement de l'application recherchée.

On peut citer:

* La récupération de l'énergie par différence de température

* Les panneaux photovoltaïques

* La récupération de l'énergie des ondes radio

* La Piézoélectricité

Dans ce projet nous utiliserons la piézoélectricité, le module de récupération ayant déjà fait partie d'une étude de IRCICA précédent le projet.

==== Le stockage de l’énergie ====

Le choix du système de stockage de l'énergie constitue une partie importante de la réalisation du système.
La problématique de cette partie sera de déterminer quel type de stockage nous utiliserons : batterie, super-capacité ou un hybride et de les dimensionner.
Il faudra tenir compte des problèmes de décharge partielle influent sur la durée de vie du stockage.

==== Le management/mise en forme de l’énergie ====

L'objectif de cette partie est d'étudier la nécessité de la mise en place d'une régulation tout en préservant des contraintes de consommation très faibles.

==== L'utilisation de l'énergie mise en forme ====

On cherche à minimiser l'énergie consommée par l'ensemble du système.

=== Contrôleur ===

Le microprocesseur : il existe différents types de microprocesseurs. L'objectif est de choisir un support capable de consommer un minimum d'énergie tout en conservant une taille minimale. Nous avons déjà utilisé dans d'autres projets des micro-contrôleurs de type Arduino et Raspberry pie. Ceux-ci ont pour avantage d’être prêts à l'emploi et faciles de prise en main. On peut s’orienter également vers un contrôleur ultra low power comme le STM32L4.

{| class="wikitable centre" width="80%"
|+
|-
! scope=col |
! scope=col | Consommation
! scope=col | Facilité de développement
! scope=col | Miniaturisation
|-
| width="33%" |
<center>Arduino</center>
| width="34%" |
<center>faible à très faible</center>
| width="33%" |
<center>bonne</center>
| width="33%" |
<center>faible</center>
|-
| width="33%" |
<center>Raspberry pi</center>
| width="34%" |
<center>importante</center>
| width="34%" |
<center>très bonne</center>
| width="34%" |
<center>très faible</center>
|-
| width="33%" |
<center>Ultra low power</center>
| width="34%" |
<center>très, très faible</center>
| width="33%" |
<center>difficile</center>
| width="33%" |
<center>forte</center>
|}

=== Capteurs ===

On peut imaginer différents types de capteurs :

* Accéléromètre

* Gyroscope

* Pression atmosphérique et altitude

* Température

* GPS

=== Mémoire ===

Le système doit être autonome et donc conserver un minimum de mesures pour les cas où la connexion est impossible. La mémoire doit être dimensionnée en fonction du nombre de capteurs, l’intervalle d’acquisition et le temps maximum avant connexion au système centralisé.

=== Protocole de communication ===

Un protocole de communication : dans un premier temps, nous nous concentrons sur le protocole BLE (Bluetooth Low Energie). Ce protocole étant standardisé, il nous permettra de recueillir de la documentation et réaliser des tests de consommation rapides.

== Planning prévisionnel ==

[[Fichier:P32Gant.PNG]]

==Suivi de l'avancement du Projet==
===Semaine 1 (28/09/2015)===

* Rencontre avec Monsieur Boe et Monsieur Giraud

* Présentation du projet

* Recherche documentaire

* Etablissement du cahier des charges

===Semaine 2 (05/10/2015)===

Recherche documentaire sur la consommation estimée des différents éléments.

{| class="wikitable centre" width="80%"
|+
|-
! scope=col | '''Contrôleur'''
! scope=col | Consommation Active
! scope=col | Consommation Inactive
! scope=col | Prix
|-
| width="33%" |
<center>Arduino Pro Mini 328 </center>
| width="34%" |
<center> 7mA (1 capteur)</center>
| width="33%" |
<center>4.5µA</center>
| width="33%" |
<center>Disponible</center>
|-
| width="33%" |
<center>STM32L4 Series (STM32L476JE)</center>
| width="34%" |
<center> 100 μA/MHz</center>
| width="33%" |
<center>120 nA</center>
| width="33%" |
<center>$5</center>
|-
| width="33%" |
<center>Raspberry</center>
| width="34%" |
<center> 200mA </center>
| width="33%" |
<center>200mA</center>
| width="33%" |
<center>Disponible</center>
|}

{| class="wikitable centre" width="80%"
|+
|-
! scope=col | '''Module BLE'''
! scope=col | Consommation
! scope=col | Options d'alimentation
! scope=col | Prix
|-
| width="33%" |
<center>BLE Mini</center>
| width="34%" |
<center> 15 mA </center>
| width="33%" |
<center>3.4V à 11V VIN / 5V USB / Coin Cell Battery (2025 or 2032) / 3.7V Li-ion Battery</center>
| width="33%" |
<center>$17</center>
|}

* <s> Le système Mini Arduino/ BLE Mini me semble être un bon compromis entre facilité d’intégration, consommation d'énergie et miniaturisation du système.</s> (Choix à discuter à la réunion du Merdredi 07/10)
* Choix du module RFduino

{| class="wikitable centre" width="80%"
|+
|-
! scope=col | '''Capteurs'''
! scope=col | Modèle
! scope=col | Alimentation min/max
! scope=col | Prix
|-
| width="33%" |
<center>Température</center>
| width="34%" |
<center> TMP36GT9Z </center>
| width="33%" |
<center>2.7V/5.5V</center>
| width="33%" |
<center>1,46 €</center>
|-
| width="33%" |
<center>Accéléromètre</center>
| width="34%" |
<center> ADXL345BCCZ </center>
| width="33%" |
<center>2V/3.6V</center>
| width="33%" |
<center>5,54 €</center>
|-
| width="33%" |
<center>Gyroscope+Accéléromètre</center>
| width="34%" |
<center> MPU-6050</center>
| width="33%" |
<center>2.5V/3.6V</center>
| width="33%" |
<center>15,73 €</center>
|-
| width="33%" |
<center>Pression atmosphérique / Altitude</center>
| width="34%" |
<center> MPL3115A2 </center>
| width="33%" |
<center>1.95V/3.6V</center>
| width="33%" |
<center>2,65 €</center>
|}

* Pour minimiser les pertes on cherche a travailler avec une tension d'alimentation la plus faible possible. Je propose de travailler avec une tension d'alimentation de 3,3V (Validé à discuter à la réunion du Merdredi 07/10)

* Le système de récupération d'énergie fonctionnant sur la base d'un mouvement, j'ai choisi l'ensemble des capteur ci dessus qui me semble être adapté à l'intégration dans un système en mouvement. (Validé à discuter à la réunion du Merdredi 07/10)

* Récupération des modules RFduino, prise en main

===Semaine 3 (12/10/2015)===

* Installation des librairies

* Visualisation d'exemples

* Tests d'implantation du code source du projet P14: Aimant intelligent de la session IMA4: 2014/2015

* Optimisation du code pour la réduction de la consommation d'énergie

* Recherches sur d'autres composants dans l'optique d'une consommation toujours plus faible

{| class="wikitable centre" width="80%"
|+
|-
! scope=col | '''Capteurs'''
! scope=col | Modèle
! scope=col | Alimentation min/max
! scope=col | Prix
! scope=col | Consommation (typ/max)
|-
| width="33%" |
<center>Température</center>
| width="34%" |
<center> STLM20W87F </center>
| width="33%" |
<center>2.4V/5.5V</center>
| width="33%" |
<center> 0,775 € </center>
| width="33%" |
<center> 4.8 μA/8.0 μA </center>
|}

'''Calcul théorique de la consommation énergétique du module BLE + RFD22301'''

Mode "endormi" : ARM CPU Running Current + Output standard drive current = 4 + 0.5 = 4.5mA

Mode "acquisition": ARM CPU Running Current + Output high drive current = 5 + 4 = 9mA

Mode "transmission" : ARM CPU Running Current + Transmit Current + Output standard drive current = 4 + 0.5 + 12 = 16.5mA

http://www.rfduino.com/wp-content/uploads/2014/03/RFD22301.Data_.Sheet_.11.24.13_11.38PM.pdf

'''Code possible du mode "endormi"'''

pinMode(5, INPUT);
RFduino_pinWake(5, HIGH);

RFduino_ULPDelay(INFINITE);
if (RFduino_pinWoke(5))
{
state = ! state;
RFduinoGZLL.sendToHost(state);
}

http://forum.rfduino.com/index.php?topic=385.0

===Semaine 4 (19/10/2015)===

* Réunion du 21/10

* Réalisation de tests

* Ajustement du nombre de capteurs : dans un premier temps on utilisera le capteur de température puis l'accéléromètre

* Discussion sur le bac de test et méthodes de test : résistance de visualisation, chronométrage du temps de transmission, vitesse du processeur

* Réalisation des premiers relevés

===Semaine 5 (26/10/2015)===

* Recherche bibliographique sur les modes d'endormissement du module RFduino

* Essais de codes utilisant un mode d'endormissement plus profond

* Réalisation de graphique de l'énergie utilisée par le module lors de la transmission d'un message par le module BLE.

* Recherches sur des méthodes de programmation pour la diminution de la vitesse processeur

[[Fichier:P32Montage.jpg|250px|thumb|left|'''Montage de test''']]
[[Fichier:P32resultats.jpg|250px|thumb|center|'''Visualisation du courant consommé lors d'envoi toutes les 10ms''']]

* On visualise à l'oscilloscope des pic d'envoi et des pic d'avertissement de la balise BLE, on peut ainsi déduire la puissance nécessaire de chaque action

===Semaine 6 (02/11/2015)===

* Test de diminution de la vitesse processeur

* Réalisation de graphique démontrant l'impact de la réduction de la vitesse processeur sur l'énergie consommée et déduction d'une vitesse optimale pour notre application

* Réunion du 4/11

Définition d'objectifs : Création d'un fichier excel permettant de caractériser les coûts en énergies de chaque étapes de fonctionnement du système.

* Création d'un environnement de test "normé" ( Pour éviter les variations de mesures on réalise un banc et on applique les mêmes conditions de test pour chaque essai)

* Recherche bibliographique sur la norme BLE : recherche du temps maximum entre deux "avertissements" de la balise BLE

===Semaine 7 (09/11/2015)===
* Explication du principe de communication BLE pour l'exploitation des résultats

[[Fichier:Freq.PNG]]

Nous nous intéressons dans notre projet à "l'observateur". Cet objet peut avoir trois états : stand-by, advertising et en communication.

[[Fichier:Brod2.png]]

Dans le mode "Advertising" le système peut :

- Avertir le système récepteur de la proximité d'un capteur

- Avertir de la présence à un appareil souhaitant ce connecter

- Ce reconnecter de façon asynchrone

===Semaine 8 (16/11/2015)===

Analyse en détail d'une trame BLE

[[Fichier:Com.PNG]]

On constate que pendant la durée de la trame il y a un échange entre les deux objets appairé. On s’intéresse ici uniquement aux actions "Slave Tx". Le but étant d'identifier la durée et le courant consommé par ces actions pour obtenir des valeurs en joules.

[[Fichier:SchemaCom.PNG]]

On constate donc deux phases :

- Advertising event

- Connexion event

Nous allons essayer de retrouver et quantifié l'énergie consommé dans ces deux phases.

===Semaine 9 (23/11/2015)===

Lors de cette semaine nous avons effectué des tests en respectant une procédure de test précise. En effet les valeurs des courants que nous relevons sont très petites aussi chaque variation du montage est susceptible de perturber les valeurs.

[[Fichier:P32Conne.jpg|250px|thumb|left|'''Phase connexion''']]

[[Fichier:Avertissement.jpg|250px|thumb|center|'''Phase Advertising''']]

===Semaine 10 (30/11/2015)===

- On cherche a diminuer légèrement la consommation par des modifications logiciel :

Réduction de la puissance de la radio BLE : Diminution de la portée

Augmentation de la fréquence d'advertising : tant que la fréquence d'advetising est inférieure a cette de relevé des capteurs on s'assure que la donnée envoyée est toujours mise à jour.

[[Fichier:Pwl20-envoi.jpg|250px|thumb|left|'''Avec modification logiciel''']]

[[Fichier:Sans-pwlvl.jpg|250px|thumb|center|'''Sans modification logiciel''']]

- On concentre nos résultats dans un tableau récapitulatif en vue du dimensionnement de la batterie du système

[[Fichier:P32tbresul.PNG]]

===Semaine 11 (07/12/2015)===

Tests d'intégration de plusieurs capteur et observations des modification de la consommation des ADC et de la durée/consommation de la transmission.

Réunion de vérification des tests.

Mise en évidence de la dualité consommation d'énergie - Temps de réponse du système

En effet chaque "Advertisement" consomme une quantité d'énergie nous pouvons gérer l'espacement entre ceux-ci mais plus ce temps serra élevé plus il faudra de temps pour ce connecter à ce périphérique.

* Rédaction d'un rapport de test

* Rédaction du rapport de pré soutenance

===Semaine 12 (14/12/2015)===
===Semaine 13 (04/01/2016)===

*Amélioration du modèle

L’amélioration du modèle est réalisée en tenant compte des facteurs influent sur la qualité de la transmission.

* Utilisation d'un picoscope : appareil permettant l’acquisition sur ordinateur de plusieurs formes d'ondes.
Ainsi grâce a un pico scope utilisé à l’IRCICA j’ai pu relever de nombreux échantillons nécessaire a une étude statistique des surcoûts en énergie.

[[Fichier:Montagemulti.jpg|250px|thumb|left|'''Montage multi récepteur''']]

===Semaine 14 (11/01/2016)===

* Compilation des résultats

* Exploitation Matlab

[[Fichier:Emistbrecap.PNG]]

===Semaine 15 (18/01/2016)===

Principe de fonctionnement du récupérateur d’énergie

Le récupérateur d’énergie fonctionne grâce à un patch piezo. Ce patch est capable de produire un courent à partir de la vélocité d’une impulsion suivent la formule :

[[Fichier:Equapiezo.PNG]]

[[Fichier:Modelepizo.PNG|250px|thumb|left|'''Modèle simplifié du patch piezo''']]

Pour récupérer de l’énergie il est couplé au système suivent :

[[Fichier:montagepiezo.PNG]]

La puissance du système est définie par :

P=V*im

L’énergie s’exprime alors :

[[Fichier:Equaenergie.PNG]]

L’énergie produite par le système est donc dépendante de la tension d’alimentation V de la constante électromécanique N et du choc produit sur le patch piezo.
Une impulsion sur le capteur piezo est de la forme :

La dérivée par rapport au temps de cette impulsion est donc de la forme :

Il est donc important de « fenêtrer » la tension pour ne récupérer que la partie positive.
Ce fenêtrage ainsi que la fréquence de commutation du hacheur est assurée par un microcontrôleur.

Dans la suite de notre étude nous ne tiendrons pas compte de la consommation de celui-ci.

===Semaine 16 (25/01/2016)===

* Réflexions sur le prototypage

* Présentation du récupérateur

* Mise en place du banc de test

* Premiers relevés

[[Fichier:Montagepiezo.jpg|250px|thumb|left|'''Montage piezo''']]
[[Fichier:Patchpiezo.jpg|250px|thumb|center|'''Patch piezo''']]

===Semaine 17 (01/02/2016)===

Test de la quantité d’énergie récupérée par un patch piezo

Méthodologie :

Channel rouge : Tension aux bornes du patch piezo. Ici on observe une fenêtre de tension de 4,5ms imposée par le microcontrôleur.

Channel vert : Tension aux bornes de la capacité C1 de 220nF
[[Fichier:Diffpot.png|250px|thumb|center]]

On constate qu’un choc sur le patch piezo produit une énergie suivent la formule, E = V * N * Δw
N étant une constante électromécanique, on va faire varier V pour évaluer le gain en énergie. Cependant Δw est généré par un choc d’un stylo sur le patch il n’est donc pas uniforme.
Nous utilisons donc une méthode statistique qui consiste à retirer deux extrémum et faire la moyenne de 10 mesures.

Nous obtenons la courbe suivante :

On constate que la courbe n’est pas linéaire comme l’aurai laissé supposer la formule. En effet jusqu’à 30V elle est linéaire croissante suivent l’équation :

Puis après 30V elle devient quadratique décroissante suivent la formule :

En effet la formule E = V * N * Δw néglige les pertes. Celles-ci deviennent plus importante a chaque augmentation de la tension d’alimentation.

On obtient donc un point de fonctionnement optimal a 30V pour notre système. Ce qui impose que notre système soit équipé d’une source de tension en conséquence.

===Semaine 18 (08/02/2016)===
===Semaine 19 (15/02/2016)===
===Semaine 20 (22/02/2016)===

== Annexes ==

Consommation du STM32L4 Series : http://www.st.com/web/en/catalog/mmc/FM141/SC1169/SS1580?sc=stm32l4

Réduction de la consommation de l'Arduino : http://www.home-automation-community.com/arduino-low-power-how-to-run-atmega328p-for-a-year-on-coin-cell-battery/

Consommation Raspberry : https://www.raspberrypi.org/help/faqs/

Module BLE : http://redbearlab.com/blemini/

Accéléromètre : http://fr.farnell.com/analog-devices/adxl345bccz/accelerometre-3-axes-14lga/dp/1853935

Capteur température : http://fr.farnell.com/analog-devices/tmp36gt9z/capteur-temp-to-92-3/dp/1438760?ost=TMP36GT9Z
ou http://fr.farnell.com/stmicroelectronics/stlm20w87f/capteur-de-temperature-analog/dp/1391131

Accéléromètre + Gyroscope : http://fr.farnell.com/invensense/mpu-6050/gyroscope-accelero-6-axes-i2c/dp/1864742

Altimètre : http://fr.farnell.com/freescale-semiconductor/mpl3115a2/pressure-sensor-20-110kpa-8lga/dp/2009084?ost=MPL3115A2&categoryId=700000004367

Explications norme BLE : chapters.comsoc.org/vancouver/BTLER3.pdf

http://www.argenox.com/bluetooth-low-energy-ble-v4-0-development/library/a-ble-advertising-primer/

== Rapport de Mi-projet ==

[[Fichier:CR_Miprojet_Sultana.pdf‎ ]]

P32 Récupération d'énergie pour balise BLE

2016-02-10T15:58:04Z

Qsultana : /* Semaine 17 (01/02/2016) */

== Objectif ==

Mon projet consiste à réaliser un système électronique autonome, composé de différents capteurs et capable de recueillir et de transmettre les données mémorisées vers un système centralisé.

== Etude préalable ==

L’énergie est le point de difficulté dans la réalisation de ce projet. Chaque élément devra être choisi non seulement pour ses performances mais également pour sa faible consommation.

== Organisation générale ==

Le système est organisé autour d’une source d’énergie, d’un contrôleur, de capteurs, de mémoire et d’un protocole de communication.

On cherche à minimiser l'énergie consommée par l'ensemble du système.

[[Fichier:P32Ensemble.PNG|250px|thumb|left|'''Architecture''']]

=== Chaine de l’énergie ===

L’énergie pour ce module autonome est constituée de quatre phases importantes :

[[Fichier:P32Energie.PNG]]

==== La récupération de l'énergie dans l'environnement ====

Il existe de nombreux moyens pour récupérer de l'énergie dans l'environnement. L'objectif est de trouver les sources les plus adaptées à l'environnement de l'application recherchée.

On peut citer:

* La récupération de l'énergie par différence de température

* Les panneaux photovoltaïques

* La récupération de l'énergie des ondes radio

* La Piézoélectricité

Dans ce projet nous utiliserons la piézoélectricité, le module de récupération ayant déjà fait partie d'une étude de IRCICA précédent le projet.

==== Le stockage de l’énergie ====

Le choix du système de stockage de l'énergie constitue une partie importante de la réalisation du système.
La problématique de cette partie sera de déterminer quel type de stockage nous utiliserons : batterie, super-capacité ou un hybride et de les dimensionner.
Il faudra tenir compte des problèmes de décharge partielle influent sur la durée de vie du stockage.

==== Le management/mise en forme de l’énergie ====

L'objectif de cette partie est d'étudier la nécessité de la mise en place d'une régulation tout en préservant des contraintes de consommation très faibles.

==== L'utilisation de l'énergie mise en forme ====

On cherche à minimiser l'énergie consommée par l'ensemble du système.

=== Contrôleur ===

Le microprocesseur : il existe différents types de microprocesseurs. L'objectif est de choisir un support capable de consommer un minimum d'énergie tout en conservant une taille minimale. Nous avons déjà utilisé dans d'autres projets des micro-contrôleurs de type Arduino et Raspberry pie. Ceux-ci ont pour avantage d’être prêts à l'emploi et faciles de prise en main. On peut s’orienter également vers un contrôleur ultra low power comme le STM32L4.

{| class="wikitable centre" width="80%"
|+
|-
! scope=col |
! scope=col | Consommation
! scope=col | Facilité de développement
! scope=col | Miniaturisation
|-
| width="33%" |
<center>Arduino</center>
| width="34%" |
<center>faible à très faible</center>
| width="33%" |
<center>bonne</center>
| width="33%" |
<center>faible</center>
|-
| width="33%" |
<center>Raspberry pi</center>
| width="34%" |
<center>importante</center>
| width="34%" |
<center>très bonne</center>
| width="34%" |
<center>très faible</center>
|-
| width="33%" |
<center>Ultra low power</center>
| width="34%" |
<center>très, très faible</center>
| width="33%" |
<center>difficile</center>
| width="33%" |
<center>forte</center>
|}

=== Capteurs ===

On peut imaginer différents types de capteurs :

* Accéléromètre

* Gyroscope

* Pression atmosphérique et altitude

* Température

* GPS

=== Mémoire ===

Le système doit être autonome et donc conserver un minimum de mesures pour les cas où la connexion est impossible. La mémoire doit être dimensionnée en fonction du nombre de capteurs, l’intervalle d’acquisition et le temps maximum avant connexion au système centralisé.

=== Protocole de communication ===

Un protocole de communication : dans un premier temps, nous nous concentrons sur le protocole BLE (Bluetooth Low Energie). Ce protocole étant standardisé, il nous permettra de recueillir de la documentation et réaliser des tests de consommation rapides.

== Planning prévisionnel ==

[[Fichier:P32Gant.PNG]]

==Suivi de l'avancement du Projet==
===Semaine 1 (28/09/2015)===

* Rencontre avec Monsieur Boe et Monsieur Giraud

* Présentation du projet

* Recherche documentaire

* Etablissement du cahier des charges

===Semaine 2 (05/10/2015)===

Recherche documentaire sur la consommation estimée des différents éléments.

{| class="wikitable centre" width="80%"
|+
|-
! scope=col | '''Contrôleur'''
! scope=col | Consommation Active
! scope=col | Consommation Inactive
! scope=col | Prix
|-
| width="33%" |
<center>Arduino Pro Mini 328 </center>
| width="34%" |
<center> 7mA (1 capteur)</center>
| width="33%" |
<center>4.5µA</center>
| width="33%" |
<center>Disponible</center>
|-
| width="33%" |
<center>STM32L4 Series (STM32L476JE)</center>
| width="34%" |
<center> 100 μA/MHz</center>
| width="33%" |
<center>120 nA</center>
| width="33%" |
<center>$5</center>
|-
| width="33%" |
<center>Raspberry</center>
| width="34%" |
<center> 200mA </center>
| width="33%" |
<center>200mA</center>
| width="33%" |
<center>Disponible</center>
|}

{| class="wikitable centre" width="80%"
|+
|-
! scope=col | '''Module BLE'''
! scope=col | Consommation
! scope=col | Options d'alimentation
! scope=col | Prix
|-
| width="33%" |
<center>BLE Mini</center>
| width="34%" |
<center> 15 mA </center>
| width="33%" |
<center>3.4V à 11V VIN / 5V USB / Coin Cell Battery (2025 or 2032) / 3.7V Li-ion Battery</center>
| width="33%" |
<center>$17</center>
|}

* <s> Le système Mini Arduino/ BLE Mini me semble être un bon compromis entre facilité d’intégration, consommation d'énergie et miniaturisation du système.</s> (Choix à discuter à la réunion du Merdredi 07/10)
* Choix du module RFduino

{| class="wikitable centre" width="80%"
|+
|-
! scope=col | '''Capteurs'''
! scope=col | Modèle
! scope=col | Alimentation min/max
! scope=col | Prix
|-
| width="33%" |
<center>Température</center>
| width="34%" |
<center> TMP36GT9Z </center>
| width="33%" |
<center>2.7V/5.5V</center>
| width="33%" |
<center>1,46 €</center>
|-
| width="33%" |
<center>Accéléromètre</center>
| width="34%" |
<center> ADXL345BCCZ </center>
| width="33%" |
<center>2V/3.6V</center>
| width="33%" |
<center>5,54 €</center>
|-
| width="33%" |
<center>Gyroscope+Accéléromètre</center>
| width="34%" |
<center> MPU-6050</center>
| width="33%" |
<center>2.5V/3.6V</center>
| width="33%" |
<center>15,73 €</center>
|-
| width="33%" |
<center>Pression atmosphérique / Altitude</center>
| width="34%" |
<center> MPL3115A2 </center>
| width="33%" |
<center>1.95V/3.6V</center>
| width="33%" |
<center>2,65 €</center>
|}

* Pour minimiser les pertes on cherche a travailler avec une tension d'alimentation la plus faible possible. Je propose de travailler avec une tension d'alimentation de 3,3V (Validé à discuter à la réunion du Merdredi 07/10)

* Le système de récupération d'énergie fonctionnant sur la base d'un mouvement, j'ai choisi l'ensemble des capteur ci dessus qui me semble être adapté à l'intégration dans un système en mouvement. (Validé à discuter à la réunion du Merdredi 07/10)

* Récupération des modules RFduino, prise en main

===Semaine 3 (12/10/2015)===

* Installation des librairies

* Visualisation d'exemples

* Tests d'implantation du code source du projet P14: Aimant intelligent de la session IMA4: 2014/2015

* Optimisation du code pour la réduction de la consommation d'énergie

* Recherches sur d'autres composants dans l'optique d'une consommation toujours plus faible

{| class="wikitable centre" width="80%"
|+
|-
! scope=col | '''Capteurs'''
! scope=col | Modèle
! scope=col | Alimentation min/max
! scope=col | Prix
! scope=col | Consommation (typ/max)
|-
| width="33%" |
<center>Température</center>
| width="34%" |
<center> STLM20W87F </center>
| width="33%" |
<center>2.4V/5.5V</center>
| width="33%" |
<center> 0,775 € </center>
| width="33%" |
<center> 4.8 μA/8.0 μA </center>
|}

'''Calcul théorique de la consommation énergétique du module BLE + RFD22301'''

Mode "endormi" : ARM CPU Running Current + Output standard drive current = 4 + 0.5 = 4.5mA

Mode "acquisition": ARM CPU Running Current + Output high drive current = 5 + 4 = 9mA

Mode "transmission" : ARM CPU Running Current + Transmit Current + Output standard drive current = 4 + 0.5 + 12 = 16.5mA

http://www.rfduino.com/wp-content/uploads/2014/03/RFD22301.Data_.Sheet_.11.24.13_11.38PM.pdf

'''Code possible du mode "endormi"'''

pinMode(5, INPUT);
RFduino_pinWake(5, HIGH);

RFduino_ULPDelay(INFINITE);
if (RFduino_pinWoke(5))
{
state = ! state;
RFduinoGZLL.sendToHost(state);
}

http://forum.rfduino.com/index.php?topic=385.0

===Semaine 4 (19/10/2015)===

* Réunion du 21/10

* Réalisation de tests

* Ajustement du nombre de capteurs : dans un premier temps on utilisera le capteur de température puis l'accéléromètre

* Discussion sur le bac de test et méthodes de test : résistance de visualisation, chronométrage du temps de transmission, vitesse du processeur

* Réalisation des premiers relevés

===Semaine 5 (26/10/2015)===

* Recherche bibliographique sur les modes d'endormissement du module RFduino

* Essais de codes utilisant un mode d'endormissement plus profond

* Réalisation de graphique de l'énergie utilisée par le module lors de la transmission d'un message par le module BLE.

* Recherches sur des méthodes de programmation pour la diminution de la vitesse processeur

[[Fichier:P32Montage.jpg|250px|thumb|left|'''Montage de test''']]
[[Fichier:P32resultats.jpg|250px|thumb|center|'''Visualisation du courant consommé lors d'envoi toutes les 10ms''']]

* On visualise à l'oscilloscope des pic d'envoi et des pic d'avertissement de la balise BLE, on peut ainsi déduire la puissance nécessaire de chaque action

===Semaine 6 (02/11/2015)===

* Test de diminution de la vitesse processeur

* Réalisation de graphique démontrant l'impact de la réduction de la vitesse processeur sur l'énergie consommée et déduction d'une vitesse optimale pour notre application

* Réunion du 4/11

Définition d'objectifs : Création d'un fichier excel permettant de caractériser les coûts en énergies de chaque étapes de fonctionnement du système.

* Création d'un environnement de test "normé" ( Pour éviter les variations de mesures on réalise un banc et on applique les mêmes conditions de test pour chaque essai)

* Recherche bibliographique sur la norme BLE : recherche du temps maximum entre deux "avertissements" de la balise BLE

===Semaine 7 (09/11/2015)===
* Explication du principe de communication BLE pour l'exploitation des résultats

[[Fichier:Freq.PNG]]

Nous nous intéressons dans notre projet à "l'observateur". Cet objet peut avoir trois états : stand-by, advertising et en communication.

[[Fichier:Brod2.png]]

Dans le mode "Advertising" le système peut :

- Avertir le système récepteur de la proximité d'un capteur

- Avertir de la présence à un appareil souhaitant ce connecter

- Ce reconnecter de façon asynchrone

===Semaine 8 (16/11/2015)===

Analyse en détail d'une trame BLE

[[Fichier:Com.PNG]]

On constate que pendant la durée de la trame il y a un échange entre les deux objets appairé. On s’intéresse ici uniquement aux actions "Slave Tx". Le but étant d'identifier la durée et le courant consommé par ces actions pour obtenir des valeurs en joules.

[[Fichier:SchemaCom.PNG]]

On constate donc deux phases :

- Advertising event

- Connexion event

Nous allons essayer de retrouver et quantifié l'énergie consommé dans ces deux phases.

===Semaine 9 (23/11/2015)===

Lors de cette semaine nous avons effectué des tests en respectant une procédure de test précise. En effet les valeurs des courants que nous relevons sont très petites aussi chaque variation du montage est susceptible de perturber les valeurs.

[[Fichier:P32Conne.jpg|250px|thumb|left|'''Phase connexion''']]

[[Fichier:Avertissement.jpg|250px|thumb|center|'''Phase Advertising''']]

===Semaine 10 (30/11/2015)===

- On cherche a diminuer légèrement la consommation par des modifications logiciel :

Réduction de la puissance de la radio BLE : Diminution de la portée

Augmentation de la fréquence d'advertising : tant que la fréquence d'advetising est inférieure a cette de relevé des capteurs on s'assure que la donnée envoyée est toujours mise à jour.

[[Fichier:Pwl20-envoi.jpg|250px|thumb|left|'''Avec modification logiciel''']]

[[Fichier:Sans-pwlvl.jpg|250px|thumb|center|'''Sans modification logiciel''']]

- On concentre nos résultats dans un tableau récapitulatif en vue du dimensionnement de la batterie du système

[[Fichier:P32tbresul.PNG]]

===Semaine 11 (07/12/2015)===

Tests d'intégration de plusieurs capteur et observations des modification de la consommation des ADC et de la durée/consommation de la transmission.

Réunion de vérification des tests.

Mise en évidence de la dualité consommation d'énergie - Temps de réponse du système

En effet chaque "Advertisement" consomme une quantité d'énergie nous pouvons gérer l'espacement entre ceux-ci mais plus ce temps serra élevé plus il faudra de temps pour ce connecter à ce périphérique.

* Rédaction d'un rapport de test

* Rédaction du rapport de pré soutenance

===Semaine 12 (14/12/2015)===
===Semaine 13 (04/01/2016)===

*Amélioration du modèle

L’amélioration du modèle est réalisée en tenant compte des facteurs influent sur la qualité de la transmission.

* Utilisation d'un picoscope : appareil permettant l’acquisition sur ordinateur de plusieurs formes d'ondes.
Ainsi grâce a un pico scope utilisé à l’IRCICA j’ai pu relever de nombreux échantillons nécessaire a une étude statistique des surcoûts en énergie.

[[Fichier:Montagemulti.jpg|250px|thumb|left|'''Montage multi récepteur''']]

===Semaine 14 (11/01/2016)===

* Compilation des résultats

* Exploitation Matlab

[[Fichier:Emistbrecap.PNG]]

===Semaine 15 (18/01/2016)===

Principe de fonctionnement du récupérateur d’énergie

Le récupérateur d’énergie fonctionne grâce à un patch piezo. Ce patch est capable de produire un courent à partir de la vélocité d’une impulsion suivent la formule :

[[Fichier:Equapiezo.PNG]]

[[Fichier:Modelepizo.PNG|250px|thumb|left|'''Modèle simplifié du patch piezo''']]

Pour récupérer de l’énergie il est couplé au système suivent :

[[Fichier:montagepiezo.PNG]]

La puissance du système est définie par :

P=V*im

L’énergie s’exprime alors :

[[Fichier:Equaenergie.PNG]]

L’énergie produite par le système est donc dépendante de la tension d’alimentation V de la constante électromécanique N et du choc produit sur le patch piezo.
Une impulsion sur le capteur piezo est de la forme :

La dérivée par rapport au temps de cette impulsion est donc de la forme :

Il est donc important de « fenêtrer » la tension pour ne récupérer que la partie positive.
Ce fenêtrage ainsi que la fréquence de commutation du hacheur est assurée par un microcontrôleur.

Dans la suite de notre étude nous ne tiendrons pas compte de la consommation de celui-ci.

===Semaine 16 (25/01/2016)===

* Réflexions sur le prototypage

* Présentation du récupérateur

* Mise en place du banc de test

* Premiers relevés

[[Fichier:Montagepiezo.jpg|250px|thumb|left|'''Montage piezo''']]
[[Fichier:Patchpiezo.jpg|250px|thumb|center|'''Patch piezo''']]

===Semaine 17 (01/02/2016)===

Test de la quantité d’énergie récupérée par un patch piezo

Méthodologie :

Channel rouge : Tension aux bornes du patch piezo. Ici on observe une fenêtre de tension de 4,5ms imposée par le microcontrôleur.

Channel vert : Tension aux bornes de la capacité C1 de 220nF
[[Fichier:Diffpot.png|250px|thumb|center]]

On constate qu’un choc sur le patch piezo produit une énergie suivent la formule, E = V * N * Δw
N étant une constante électromécanique, on va faire varier V pour évaluer le gain en énergie. Cependant Δw est généré par un choc d’un stylo sur le patch il n’est donc pas uniforme.
Nous utilisons donc une méthode statistique qui consiste à retirer deux extrémum et faire la moyenne de 10 mesures.

Nous obtenons la courbe suivante :

On constate que la courbe n’est pas linéaire comme l’aurai laissé supposer la formule. En effet jusqu’à 30V elle est linéaire croissante suivent l’équation :

Puis après 30V elle devient quadratique décroissante suivent la formule :

En effet la formule E = V * N * Δw néglige les pertes. Celles-ci deviennent plus importante a chaque augmentation de la tension d’alimentation.

On obtient donc un point de fonctionnement optimal a 30V pour notre système. Ce qui impose que notre système soit équipé d’une source de tension en conséquence.

===Semaine 18 (08/02/2016)===
===Semaine 19 (15/02/2016)===
===Semaine 20 (22/02/2016)===

== Annexes ==

Consommation du STM32L4 Series : http://www.st.com/web/en/catalog/mmc/FM141/SC1169/SS1580?sc=stm32l4

Réduction de la consommation de l'Arduino : http://www.home-automation-community.com/arduino-low-power-how-to-run-atmega328p-for-a-year-on-coin-cell-battery/

Consommation Raspberry : https://www.raspberrypi.org/help/faqs/

Module BLE : http://redbearlab.com/blemini/

Accéléromètre : http://fr.farnell.com/analog-devices/adxl345bccz/accelerometre-3-axes-14lga/dp/1853935

Capteur température : http://fr.farnell.com/analog-devices/tmp36gt9z/capteur-temp-to-92-3/dp/1438760?ost=TMP36GT9Z
ou http://fr.farnell.com/stmicroelectronics/stlm20w87f/capteur-de-temperature-analog/dp/1391131

Accéléromètre + Gyroscope : http://fr.farnell.com/invensense/mpu-6050/gyroscope-accelero-6-axes-i2c/dp/1864742

Altimètre : http://fr.farnell.com/freescale-semiconductor/mpl3115a2/pressure-sensor-20-110kpa-8lga/dp/2009084?ost=MPL3115A2&categoryId=700000004367

Explications norme BLE : chapters.comsoc.org/vancouver/BTLER3.pdf

http://www.argenox.com/bluetooth-low-energy-ble-v4-0-development/library/a-ble-advertising-primer/

== Rapport de Mi-projet ==

[[Fichier:CR_Miprojet_Sultana.pdf‎ ]]

P32 Récupération d'énergie pour balise BLE

2016-02-10T15:57:37Z

Qsultana : /* Semaine 17 (01/02/2016) */

== Objectif ==

Mon projet consiste à réaliser un système électronique autonome, composé de différents capteurs et capable de recueillir et de transmettre les données mémorisées vers un système centralisé.

== Etude préalable ==

L’énergie est le point de difficulté dans la réalisation de ce projet. Chaque élément devra être choisi non seulement pour ses performances mais également pour sa faible consommation.

== Organisation générale ==

Le système est organisé autour d’une source d’énergie, d’un contrôleur, de capteurs, de mémoire et d’un protocole de communication.

On cherche à minimiser l'énergie consommée par l'ensemble du système.

[[Fichier:P32Ensemble.PNG|250px|thumb|left|'''Architecture''']]

=== Chaine de l’énergie ===

L’énergie pour ce module autonome est constituée de quatre phases importantes :

[[Fichier:P32Energie.PNG]]

==== La récupération de l'énergie dans l'environnement ====

Il existe de nombreux moyens pour récupérer de l'énergie dans l'environnement. L'objectif est de trouver les sources les plus adaptées à l'environnement de l'application recherchée.

On peut citer:

* La récupération de l'énergie par différence de température

* Les panneaux photovoltaïques

* La récupération de l'énergie des ondes radio

* La Piézoélectricité

Dans ce projet nous utiliserons la piézoélectricité, le module de récupération ayant déjà fait partie d'une étude de IRCICA précédent le projet.

==== Le stockage de l’énergie ====

Le choix du système de stockage de l'énergie constitue une partie importante de la réalisation du système.
La problématique de cette partie sera de déterminer quel type de stockage nous utiliserons : batterie, super-capacité ou un hybride et de les dimensionner.
Il faudra tenir compte des problèmes de décharge partielle influent sur la durée de vie du stockage.

==== Le management/mise en forme de l’énergie ====

L'objectif de cette partie est d'étudier la nécessité de la mise en place d'une régulation tout en préservant des contraintes de consommation très faibles.

==== L'utilisation de l'énergie mise en forme ====

On cherche à minimiser l'énergie consommée par l'ensemble du système.

=== Contrôleur ===

Le microprocesseur : il existe différents types de microprocesseurs. L'objectif est de choisir un support capable de consommer un minimum d'énergie tout en conservant une taille minimale. Nous avons déjà utilisé dans d'autres projets des micro-contrôleurs de type Arduino et Raspberry pie. Ceux-ci ont pour avantage d’être prêts à l'emploi et faciles de prise en main. On peut s’orienter également vers un contrôleur ultra low power comme le STM32L4.

{| class="wikitable centre" width="80%"
|+
|-
! scope=col |
! scope=col | Consommation
! scope=col | Facilité de développement
! scope=col | Miniaturisation
|-
| width="33%" |
<center>Arduino</center>
| width="34%" |
<center>faible à très faible</center>
| width="33%" |
<center>bonne</center>
| width="33%" |
<center>faible</center>
|-
| width="33%" |
<center>Raspberry pi</center>
| width="34%" |
<center>importante</center>
| width="34%" |
<center>très bonne</center>
| width="34%" |
<center>très faible</center>
|-
| width="33%" |
<center>Ultra low power</center>
| width="34%" |
<center>très, très faible</center>
| width="33%" |
<center>difficile</center>
| width="33%" |
<center>forte</center>
|}

=== Capteurs ===

On peut imaginer différents types de capteurs :

* Accéléromètre

* Gyroscope

* Pression atmosphérique et altitude

* Température

* GPS

=== Mémoire ===

Le système doit être autonome et donc conserver un minimum de mesures pour les cas où la connexion est impossible. La mémoire doit être dimensionnée en fonction du nombre de capteurs, l’intervalle d’acquisition et le temps maximum avant connexion au système centralisé.

=== Protocole de communication ===

Un protocole de communication : dans un premier temps, nous nous concentrons sur le protocole BLE (Bluetooth Low Energie). Ce protocole étant standardisé, il nous permettra de recueillir de la documentation et réaliser des tests de consommation rapides.

== Planning prévisionnel ==

[[Fichier:P32Gant.PNG]]

==Suivi de l'avancement du Projet==
===Semaine 1 (28/09/2015)===

* Rencontre avec Monsieur Boe et Monsieur Giraud

* Présentation du projet

* Recherche documentaire

* Etablissement du cahier des charges

===Semaine 2 (05/10/2015)===

Recherche documentaire sur la consommation estimée des différents éléments.

{| class="wikitable centre" width="80%"
|+
|-
! scope=col | '''Contrôleur'''
! scope=col | Consommation Active
! scope=col | Consommation Inactive
! scope=col | Prix
|-
| width="33%" |
<center>Arduino Pro Mini 328 </center>
| width="34%" |
<center> 7mA (1 capteur)</center>
| width="33%" |
<center>4.5µA</center>
| width="33%" |
<center>Disponible</center>
|-
| width="33%" |
<center>STM32L4 Series (STM32L476JE)</center>
| width="34%" |
<center> 100 μA/MHz</center>
| width="33%" |
<center>120 nA</center>
| width="33%" |
<center>$5</center>
|-
| width="33%" |
<center>Raspberry</center>
| width="34%" |
<center> 200mA </center>
| width="33%" |
<center>200mA</center>
| width="33%" |
<center>Disponible</center>
|}

{| class="wikitable centre" width="80%"
|+
|-
! scope=col | '''Module BLE'''
! scope=col | Consommation
! scope=col | Options d'alimentation
! scope=col | Prix
|-
| width="33%" |
<center>BLE Mini</center>
| width="34%" |
<center> 15 mA </center>
| width="33%" |
<center>3.4V à 11V VIN / 5V USB / Coin Cell Battery (2025 or 2032) / 3.7V Li-ion Battery</center>
| width="33%" |
<center>$17</center>
|}

* <s> Le système Mini Arduino/ BLE Mini me semble être un bon compromis entre facilité d’intégration, consommation d'énergie et miniaturisation du système.</s> (Choix à discuter à la réunion du Merdredi 07/10)
* Choix du module RFduino

{| class="wikitable centre" width="80%"
|+
|-
! scope=col | '''Capteurs'''
! scope=col | Modèle
! scope=col | Alimentation min/max
! scope=col | Prix
|-
| width="33%" |
<center>Température</center>
| width="34%" |
<center> TMP36GT9Z </center>
| width="33%" |
<center>2.7V/5.5V</center>
| width="33%" |
<center>1,46 €</center>
|-
| width="33%" |
<center>Accéléromètre</center>
| width="34%" |
<center> ADXL345BCCZ </center>
| width="33%" |
<center>2V/3.6V</center>
| width="33%" |
<center>5,54 €</center>
|-
| width="33%" |
<center>Gyroscope+Accéléromètre</center>
| width="34%" |
<center> MPU-6050</center>
| width="33%" |
<center>2.5V/3.6V</center>
| width="33%" |
<center>15,73 €</center>
|-
| width="33%" |
<center>Pression atmosphérique / Altitude</center>
| width="34%" |
<center> MPL3115A2 </center>
| width="33%" |
<center>1.95V/3.6V</center>
| width="33%" |
<center>2,65 €</center>
|}

* Pour minimiser les pertes on cherche a travailler avec une tension d'alimentation la plus faible possible. Je propose de travailler avec une tension d'alimentation de 3,3V (Validé à discuter à la réunion du Merdredi 07/10)

* Le système de récupération d'énergie fonctionnant sur la base d'un mouvement, j'ai choisi l'ensemble des capteur ci dessus qui me semble être adapté à l'intégration dans un système en mouvement. (Validé à discuter à la réunion du Merdredi 07/10)

* Récupération des modules RFduino, prise en main

===Semaine 3 (12/10/2015)===

* Installation des librairies

* Visualisation d'exemples

* Tests d'implantation du code source du projet P14: Aimant intelligent de la session IMA4: 2014/2015

* Optimisation du code pour la réduction de la consommation d'énergie

* Recherches sur d'autres composants dans l'optique d'une consommation toujours plus faible

{| class="wikitable centre" width="80%"
|+
|-
! scope=col | '''Capteurs'''
! scope=col | Modèle
! scope=col | Alimentation min/max
! scope=col | Prix
! scope=col | Consommation (typ/max)
|-
| width="33%" |
<center>Température</center>
| width="34%" |
<center> STLM20W87F </center>
| width="33%" |
<center>2.4V/5.5V</center>
| width="33%" |
<center> 0,775 € </center>
| width="33%" |
<center> 4.8 μA/8.0 μA </center>
|}

'''Calcul théorique de la consommation énergétique du module BLE + RFD22301'''

Mode "endormi" : ARM CPU Running Current + Output standard drive current = 4 + 0.5 = 4.5mA

Mode "acquisition": ARM CPU Running Current + Output high drive current = 5 + 4 = 9mA

Mode "transmission" : ARM CPU Running Current + Transmit Current + Output standard drive current = 4 + 0.5 + 12 = 16.5mA

http://www.rfduino.com/wp-content/uploads/2014/03/RFD22301.Data_.Sheet_.11.24.13_11.38PM.pdf

'''Code possible du mode "endormi"'''

pinMode(5, INPUT);
RFduino_pinWake(5, HIGH);

RFduino_ULPDelay(INFINITE);
if (RFduino_pinWoke(5))
{
state = ! state;
RFduinoGZLL.sendToHost(state);
}

http://forum.rfduino.com/index.php?topic=385.0

===Semaine 4 (19/10/2015)===

* Réunion du 21/10

* Réalisation de tests

* Ajustement du nombre de capteurs : dans un premier temps on utilisera le capteur de température puis l'accéléromètre

* Discussion sur le bac de test et méthodes de test : résistance de visualisation, chronométrage du temps de transmission, vitesse du processeur

* Réalisation des premiers relevés

===Semaine 5 (26/10/2015)===

* Recherche bibliographique sur les modes d'endormissement du module RFduino

* Essais de codes utilisant un mode d'endormissement plus profond

* Réalisation de graphique de l'énergie utilisée par le module lors de la transmission d'un message par le module BLE.

* Recherches sur des méthodes de programmation pour la diminution de la vitesse processeur

[[Fichier:P32Montage.jpg|250px|thumb|left|'''Montage de test''']]
[[Fichier:P32resultats.jpg|250px|thumb|center|'''Visualisation du courant consommé lors d'envoi toutes les 10ms''']]

* On visualise à l'oscilloscope des pic d'envoi et des pic d'avertissement de la balise BLE, on peut ainsi déduire la puissance nécessaire de chaque action

===Semaine 6 (02/11/2015)===

* Test de diminution de la vitesse processeur

* Réalisation de graphique démontrant l'impact de la réduction de la vitesse processeur sur l'énergie consommée et déduction d'une vitesse optimale pour notre application

* Réunion du 4/11

Définition d'objectifs : Création d'un fichier excel permettant de caractériser les coûts en énergies de chaque étapes de fonctionnement du système.

* Création d'un environnement de test "normé" ( Pour éviter les variations de mesures on réalise un banc et on applique les mêmes conditions de test pour chaque essai)

* Recherche bibliographique sur la norme BLE : recherche du temps maximum entre deux "avertissements" de la balise BLE

===Semaine 7 (09/11/2015)===
* Explication du principe de communication BLE pour l'exploitation des résultats

[[Fichier:Freq.PNG]]

Nous nous intéressons dans notre projet à "l'observateur". Cet objet peut avoir trois états : stand-by, advertising et en communication.

[[Fichier:Brod2.png]]

Dans le mode "Advertising" le système peut :

- Avertir le système récepteur de la proximité d'un capteur

- Avertir de la présence à un appareil souhaitant ce connecter

- Ce reconnecter de façon asynchrone

===Semaine 8 (16/11/2015)===

Analyse en détail d'une trame BLE

[[Fichier:Com.PNG]]

On constate que pendant la durée de la trame il y a un échange entre les deux objets appairé. On s’intéresse ici uniquement aux actions "Slave Tx". Le but étant d'identifier la durée et le courant consommé par ces actions pour obtenir des valeurs en joules.

[[Fichier:SchemaCom.PNG]]

On constate donc deux phases :

- Advertising event

- Connexion event

Nous allons essayer de retrouver et quantifié l'énergie consommé dans ces deux phases.

===Semaine 9 (23/11/2015)===

Lors de cette semaine nous avons effectué des tests en respectant une procédure de test précise. En effet les valeurs des courants que nous relevons sont très petites aussi chaque variation du montage est susceptible de perturber les valeurs.

[[Fichier:P32Conne.jpg|250px|thumb|left|'''Phase connexion''']]

[[Fichier:Avertissement.jpg|250px|thumb|center|'''Phase Advertising''']]

===Semaine 10 (30/11/2015)===

- On cherche a diminuer légèrement la consommation par des modifications logiciel :

Réduction de la puissance de la radio BLE : Diminution de la portée

Augmentation de la fréquence d'advertising : tant que la fréquence d'advetising est inférieure a cette de relevé des capteurs on s'assure que la donnée envoyée est toujours mise à jour.

[[Fichier:Pwl20-envoi.jpg|250px|thumb|left|'''Avec modification logiciel''']]

[[Fichier:Sans-pwlvl.jpg|250px|thumb|center|'''Sans modification logiciel''']]

- On concentre nos résultats dans un tableau récapitulatif en vue du dimensionnement de la batterie du système

[[Fichier:P32tbresul.PNG]]

===Semaine 11 (07/12/2015)===

Tests d'intégration de plusieurs capteur et observations des modification de la consommation des ADC et de la durée/consommation de la transmission.

Réunion de vérification des tests.

Mise en évidence de la dualité consommation d'énergie - Temps de réponse du système

En effet chaque "Advertisement" consomme une quantité d'énergie nous pouvons gérer l'espacement entre ceux-ci mais plus ce temps serra élevé plus il faudra de temps pour ce connecter à ce périphérique.

* Rédaction d'un rapport de test

* Rédaction du rapport de pré soutenance

===Semaine 12 (14/12/2015)===
===Semaine 13 (04/01/2016)===

*Amélioration du modèle

L’amélioration du modèle est réalisée en tenant compte des facteurs influent sur la qualité de la transmission.

* Utilisation d'un picoscope : appareil permettant l’acquisition sur ordinateur de plusieurs formes d'ondes.
Ainsi grâce a un pico scope utilisé à l’IRCICA j’ai pu relever de nombreux échantillons nécessaire a une étude statistique des surcoûts en énergie.

[[Fichier:Montagemulti.jpg|250px|thumb|left|'''Montage multi récepteur''']]

===Semaine 14 (11/01/2016)===

* Compilation des résultats

* Exploitation Matlab

[[Fichier:Emistbrecap.PNG]]

===Semaine 15 (18/01/2016)===

Principe de fonctionnement du récupérateur d’énergie

Le récupérateur d’énergie fonctionne grâce à un patch piezo. Ce patch est capable de produire un courent à partir de la vélocité d’une impulsion suivent la formule :

[[Fichier:Equapiezo.PNG]]

[[Fichier:Modelepizo.PNG|250px|thumb|left|'''Modèle simplifié du patch piezo''']]

Pour récupérer de l’énergie il est couplé au système suivent :

[[Fichier:montagepiezo.PNG]]

La puissance du système est définie par :

P=V*im

L’énergie s’exprime alors :

[[Fichier:Equaenergie.PNG]]

L’énergie produite par le système est donc dépendante de la tension d’alimentation V de la constante électromécanique N et du choc produit sur le patch piezo.
Une impulsion sur le capteur piezo est de la forme :

La dérivée par rapport au temps de cette impulsion est donc de la forme :

Il est donc important de « fenêtrer » la tension pour ne récupérer que la partie positive.
Ce fenêtrage ainsi que la fréquence de commutation du hacheur est assurée par un microcontrôleur.

Dans la suite de notre étude nous ne tiendrons pas compte de la consommation de celui-ci.

===Semaine 16 (25/01/2016)===

* Réflexions sur le prototypage

* Présentation du récupérateur

* Mise en place du banc de test

* Premiers relevés

[[Fichier:Montagepiezo.jpg|250px|thumb|left|'''Montage piezo''']]
[[Fichier:Patchpiezo.jpg|250px|thumb|center|'''Patch piezo''']]

===Semaine 17 (01/02/2016)===

Test de la quantité d’énergie récupérée par un patch piezo

Méthodologie :

Channel rouge : Tension aux bornes du patch piezo. Ici on observe une fenêtre de tension de 4,5ms imposée par le microcontrôleur.

Channel vert : Tension aux bornes de la capacité C1 de 220nF
[[Fichier:Diffpot.png|250px|thumb|center]]

On constate qu’un choc sur le patch piezo produit une énergie suivent la formule, E = V * N * Δw
N étant une constante électromécanique, on va faire varier V pour évaluer le gain en énergie. Cependant Δw est généré par un choc d’un stylo sur le patch il n’est donc pas uniforme.
Nous utilisons donc une méthode statistique qui consiste à retirer deux extrémum et faire la moyenne de 10 mesures.

Nous obtenons la courbe suivante :

On constate que la courbe n’est pas linéaire comme l’aurai laissé supposer la formule. En effet jusqu’à 30V elle est linéaire croissante suivent l’équation :

Puis après 30V elle devient quadratique décroissante suivent la formule :

En effet la formule E = V * N * Δw néglige les pertes. Celles-ci deviennent plus importante a chaque augmentation de la tension d’alimentation.

On obtient donc un point de fonctionnement optimal a 30V pour notre système. Ce qui impose que notre système soit équipé d’une source de tension en conséquence.

===Semaine 18 (08/02/2016)===
===Semaine 19 (15/02/2016)===
===Semaine 20 (22/02/2016)===

== Annexes ==

Consommation du STM32L4 Series : http://www.st.com/web/en/catalog/mmc/FM141/SC1169/SS1580?sc=stm32l4

Réduction de la consommation de l'Arduino : http://www.home-automation-community.com/arduino-low-power-how-to-run-atmega328p-for-a-year-on-coin-cell-battery/

Consommation Raspberry : https://www.raspberrypi.org/help/faqs/

Module BLE : http://redbearlab.com/blemini/

Accéléromètre : http://fr.farnell.com/analog-devices/adxl345bccz/accelerometre-3-axes-14lga/dp/1853935

Capteur température : http://fr.farnell.com/analog-devices/tmp36gt9z/capteur-temp-to-92-3/dp/1438760?ost=TMP36GT9Z
ou http://fr.farnell.com/stmicroelectronics/stlm20w87f/capteur-de-temperature-analog/dp/1391131

Accéléromètre + Gyroscope : http://fr.farnell.com/invensense/mpu-6050/gyroscope-accelero-6-axes-i2c/dp/1864742

Altimètre : http://fr.farnell.com/freescale-semiconductor/mpl3115a2/pressure-sensor-20-110kpa-8lga/dp/2009084?ost=MPL3115A2&categoryId=700000004367

Explications norme BLE : chapters.comsoc.org/vancouver/BTLER3.pdf

http://www.argenox.com/bluetooth-low-energy-ble-v4-0-development/library/a-ble-advertising-primer/

== Rapport de Mi-projet ==

[[Fichier:CR_Miprojet_Sultana.pdf‎ ]]

P32 Récupération d'énergie pour balise BLE

2016-02-10T15:57:14Z

Qsultana : /* Semaine 17 (01/02/2016) */

== Objectif ==

Mon projet consiste à réaliser un système électronique autonome, composé de différents capteurs et capable de recueillir et de transmettre les données mémorisées vers un système centralisé.

== Etude préalable ==

L’énergie est le point de difficulté dans la réalisation de ce projet. Chaque élément devra être choisi non seulement pour ses performances mais également pour sa faible consommation.

== Organisation générale ==

Le système est organisé autour d’une source d’énergie, d’un contrôleur, de capteurs, de mémoire et d’un protocole de communication.

On cherche à minimiser l'énergie consommée par l'ensemble du système.

[[Fichier:P32Ensemble.PNG|250px|thumb|left|'''Architecture''']]

=== Chaine de l’énergie ===

L’énergie pour ce module autonome est constituée de quatre phases importantes :

[[Fichier:P32Energie.PNG]]

==== La récupération de l'énergie dans l'environnement ====

Il existe de nombreux moyens pour récupérer de l'énergie dans l'environnement. L'objectif est de trouver les sources les plus adaptées à l'environnement de l'application recherchée.

On peut citer:

* La récupération de l'énergie par différence de température

* Les panneaux photovoltaïques

* La récupération de l'énergie des ondes radio

* La Piézoélectricité

Dans ce projet nous utiliserons la piézoélectricité, le module de récupération ayant déjà fait partie d'une étude de IRCICA précédent le projet.

==== Le stockage de l’énergie ====

Le choix du système de stockage de l'énergie constitue une partie importante de la réalisation du système.
La problématique de cette partie sera de déterminer quel type de stockage nous utiliserons : batterie, super-capacité ou un hybride et de les dimensionner.
Il faudra tenir compte des problèmes de décharge partielle influent sur la durée de vie du stockage.

==== Le management/mise en forme de l’énergie ====

L'objectif de cette partie est d'étudier la nécessité de la mise en place d'une régulation tout en préservant des contraintes de consommation très faibles.

==== L'utilisation de l'énergie mise en forme ====

On cherche à minimiser l'énergie consommée par l'ensemble du système.

=== Contrôleur ===

Le microprocesseur : il existe différents types de microprocesseurs. L'objectif est de choisir un support capable de consommer un minimum d'énergie tout en conservant une taille minimale. Nous avons déjà utilisé dans d'autres projets des micro-contrôleurs de type Arduino et Raspberry pie. Ceux-ci ont pour avantage d’être prêts à l'emploi et faciles de prise en main. On peut s’orienter également vers un contrôleur ultra low power comme le STM32L4.

{| class="wikitable centre" width="80%"
|+
|-
! scope=col |
! scope=col | Consommation
! scope=col | Facilité de développement
! scope=col | Miniaturisation
|-
| width="33%" |
<center>Arduino</center>
| width="34%" |
<center>faible à très faible</center>
| width="33%" |
<center>bonne</center>
| width="33%" |
<center>faible</center>
|-
| width="33%" |
<center>Raspberry pi</center>
| width="34%" |
<center>importante</center>
| width="34%" |
<center>très bonne</center>
| width="34%" |
<center>très faible</center>
|-
| width="33%" |
<center>Ultra low power</center>
| width="34%" |
<center>très, très faible</center>
| width="33%" |
<center>difficile</center>
| width="33%" |
<center>forte</center>
|}

=== Capteurs ===

On peut imaginer différents types de capteurs :

* Accéléromètre

* Gyroscope

* Pression atmosphérique et altitude

* Température

* GPS

=== Mémoire ===

Le système doit être autonome et donc conserver un minimum de mesures pour les cas où la connexion est impossible. La mémoire doit être dimensionnée en fonction du nombre de capteurs, l’intervalle d’acquisition et le temps maximum avant connexion au système centralisé.

=== Protocole de communication ===

Un protocole de communication : dans un premier temps, nous nous concentrons sur le protocole BLE (Bluetooth Low Energie). Ce protocole étant standardisé, il nous permettra de recueillir de la documentation et réaliser des tests de consommation rapides.

== Planning prévisionnel ==

[[Fichier:P32Gant.PNG]]

==Suivi de l'avancement du Projet==
===Semaine 1 (28/09/2015)===

* Rencontre avec Monsieur Boe et Monsieur Giraud

* Présentation du projet

* Recherche documentaire

* Etablissement du cahier des charges

===Semaine 2 (05/10/2015)===

Recherche documentaire sur la consommation estimée des différents éléments.

{| class="wikitable centre" width="80%"
|+
|-
! scope=col | '''Contrôleur'''
! scope=col | Consommation Active
! scope=col | Consommation Inactive
! scope=col | Prix
|-
| width="33%" |
<center>Arduino Pro Mini 328 </center>
| width="34%" |
<center> 7mA (1 capteur)</center>
| width="33%" |
<center>4.5µA</center>
| width="33%" |
<center>Disponible</center>
|-
| width="33%" |
<center>STM32L4 Series (STM32L476JE)</center>
| width="34%" |
<center> 100 μA/MHz</center>
| width="33%" |
<center>120 nA</center>
| width="33%" |
<center>$5</center>
|-
| width="33%" |
<center>Raspberry</center>
| width="34%" |
<center> 200mA </center>
| width="33%" |
<center>200mA</center>
| width="33%" |
<center>Disponible</center>
|}

{| class="wikitable centre" width="80%"
|+
|-
! scope=col | '''Module BLE'''
! scope=col | Consommation
! scope=col | Options d'alimentation
! scope=col | Prix
|-
| width="33%" |
<center>BLE Mini</center>
| width="34%" |
<center> 15 mA </center>
| width="33%" |
<center>3.4V à 11V VIN / 5V USB / Coin Cell Battery (2025 or 2032) / 3.7V Li-ion Battery</center>
| width="33%" |
<center>$17</center>
|}

* <s> Le système Mini Arduino/ BLE Mini me semble être un bon compromis entre facilité d’intégration, consommation d'énergie et miniaturisation du système.</s> (Choix à discuter à la réunion du Merdredi 07/10)
* Choix du module RFduino

{| class="wikitable centre" width="80%"
|+
|-
! scope=col | '''Capteurs'''
! scope=col | Modèle
! scope=col | Alimentation min/max
! scope=col | Prix
|-
| width="33%" |
<center>Température</center>
| width="34%" |
<center> TMP36GT9Z </center>
| width="33%" |
<center>2.7V/5.5V</center>
| width="33%" |
<center>1,46 €</center>
|-
| width="33%" |
<center>Accéléromètre</center>
| width="34%" |
<center> ADXL345BCCZ </center>
| width="33%" |
<center>2V/3.6V</center>
| width="33%" |
<center>5,54 €</center>
|-
| width="33%" |
<center>Gyroscope+Accéléromètre</center>
| width="34%" |
<center> MPU-6050</center>
| width="33%" |
<center>2.5V/3.6V</center>
| width="33%" |
<center>15,73 €</center>
|-
| width="33%" |
<center>Pression atmosphérique / Altitude</center>
| width="34%" |
<center> MPL3115A2 </center>
| width="33%" |
<center>1.95V/3.6V</center>
| width="33%" |
<center>2,65 €</center>
|}

* Pour minimiser les pertes on cherche a travailler avec une tension d'alimentation la plus faible possible. Je propose de travailler avec une tension d'alimentation de 3,3V (Validé à discuter à la réunion du Merdredi 07/10)

* Le système de récupération d'énergie fonctionnant sur la base d'un mouvement, j'ai choisi l'ensemble des capteur ci dessus qui me semble être adapté à l'intégration dans un système en mouvement. (Validé à discuter à la réunion du Merdredi 07/10)

* Récupération des modules RFduino, prise en main

===Semaine 3 (12/10/2015)===

* Installation des librairies

* Visualisation d'exemples

* Tests d'implantation du code source du projet P14: Aimant intelligent de la session IMA4: 2014/2015

* Optimisation du code pour la réduction de la consommation d'énergie

* Recherches sur d'autres composants dans l'optique d'une consommation toujours plus faible

{| class="wikitable centre" width="80%"
|+
|-
! scope=col | '''Capteurs'''
! scope=col | Modèle
! scope=col | Alimentation min/max
! scope=col | Prix
! scope=col | Consommation (typ/max)
|-
| width="33%" |
<center>Température</center>
| width="34%" |
<center> STLM20W87F </center>
| width="33%" |
<center>2.4V/5.5V</center>
| width="33%" |
<center> 0,775 € </center>
| width="33%" |
<center> 4.8 μA/8.0 μA </center>
|}

'''Calcul théorique de la consommation énergétique du module BLE + RFD22301'''

Mode "endormi" : ARM CPU Running Current + Output standard drive current = 4 + 0.5 = 4.5mA

Mode "acquisition": ARM CPU Running Current + Output high drive current = 5 + 4 = 9mA

Mode "transmission" : ARM CPU Running Current + Transmit Current + Output standard drive current = 4 + 0.5 + 12 = 16.5mA

http://www.rfduino.com/wp-content/uploads/2014/03/RFD22301.Data_.Sheet_.11.24.13_11.38PM.pdf

'''Code possible du mode "endormi"'''

pinMode(5, INPUT);
RFduino_pinWake(5, HIGH);

RFduino_ULPDelay(INFINITE);
if (RFduino_pinWoke(5))
{
state = ! state;
RFduinoGZLL.sendToHost(state);
}

http://forum.rfduino.com/index.php?topic=385.0

===Semaine 4 (19/10/2015)===

* Réunion du 21/10

* Réalisation de tests

* Ajustement du nombre de capteurs : dans un premier temps on utilisera le capteur de température puis l'accéléromètre

* Discussion sur le bac de test et méthodes de test : résistance de visualisation, chronométrage du temps de transmission, vitesse du processeur

* Réalisation des premiers relevés

===Semaine 5 (26/10/2015)===

* Recherche bibliographique sur les modes d'endormissement du module RFduino

* Essais de codes utilisant un mode d'endormissement plus profond

* Réalisation de graphique de l'énergie utilisée par le module lors de la transmission d'un message par le module BLE.

* Recherches sur des méthodes de programmation pour la diminution de la vitesse processeur

[[Fichier:P32Montage.jpg|250px|thumb|left|'''Montage de test''']]
[[Fichier:P32resultats.jpg|250px|thumb|center|'''Visualisation du courant consommé lors d'envoi toutes les 10ms''']]

* On visualise à l'oscilloscope des pic d'envoi et des pic d'avertissement de la balise BLE, on peut ainsi déduire la puissance nécessaire de chaque action

===Semaine 6 (02/11/2015)===

* Test de diminution de la vitesse processeur

* Réalisation de graphique démontrant l'impact de la réduction de la vitesse processeur sur l'énergie consommée et déduction d'une vitesse optimale pour notre application

* Réunion du 4/11

Définition d'objectifs : Création d'un fichier excel permettant de caractériser les coûts en énergies de chaque étapes de fonctionnement du système.

* Création d'un environnement de test "normé" ( Pour éviter les variations de mesures on réalise un banc et on applique les mêmes conditions de test pour chaque essai)

* Recherche bibliographique sur la norme BLE : recherche du temps maximum entre deux "avertissements" de la balise BLE

===Semaine 7 (09/11/2015)===
* Explication du principe de communication BLE pour l'exploitation des résultats

[[Fichier:Freq.PNG]]

Nous nous intéressons dans notre projet à "l'observateur". Cet objet peut avoir trois états : stand-by, advertising et en communication.

[[Fichier:Brod2.png]]

Dans le mode "Advertising" le système peut :

- Avertir le système récepteur de la proximité d'un capteur

- Avertir de la présence à un appareil souhaitant ce connecter

- Ce reconnecter de façon asynchrone

===Semaine 8 (16/11/2015)===

Analyse en détail d'une trame BLE

[[Fichier:Com.PNG]]

On constate que pendant la durée de la trame il y a un échange entre les deux objets appairé. On s’intéresse ici uniquement aux actions "Slave Tx". Le but étant d'identifier la durée et le courant consommé par ces actions pour obtenir des valeurs en joules.

[[Fichier:SchemaCom.PNG]]

On constate donc deux phases :

- Advertising event

- Connexion event

Nous allons essayer de retrouver et quantifié l'énergie consommé dans ces deux phases.

===Semaine 9 (23/11/2015)===

Lors de cette semaine nous avons effectué des tests en respectant une procédure de test précise. En effet les valeurs des courants que nous relevons sont très petites aussi chaque variation du montage est susceptible de perturber les valeurs.

[[Fichier:P32Conne.jpg|250px|thumb|left|'''Phase connexion''']]

[[Fichier:Avertissement.jpg|250px|thumb|center|'''Phase Advertising''']]

===Semaine 10 (30/11/2015)===

- On cherche a diminuer légèrement la consommation par des modifications logiciel :

Réduction de la puissance de la radio BLE : Diminution de la portée

Augmentation de la fréquence d'advertising : tant que la fréquence d'advetising est inférieure a cette de relevé des capteurs on s'assure que la donnée envoyée est toujours mise à jour.

[[Fichier:Pwl20-envoi.jpg|250px|thumb|left|'''Avec modification logiciel''']]

[[Fichier:Sans-pwlvl.jpg|250px|thumb|center|'''Sans modification logiciel''']]

- On concentre nos résultats dans un tableau récapitulatif en vue du dimensionnement de la batterie du système

[[Fichier:P32tbresul.PNG]]

===Semaine 11 (07/12/2015)===

Tests d'intégration de plusieurs capteur et observations des modification de la consommation des ADC et de la durée/consommation de la transmission.

Réunion de vérification des tests.

Mise en évidence de la dualité consommation d'énergie - Temps de réponse du système

En effet chaque "Advertisement" consomme une quantité d'énergie nous pouvons gérer l'espacement entre ceux-ci mais plus ce temps serra élevé plus il faudra de temps pour ce connecter à ce périphérique.

* Rédaction d'un rapport de test

* Rédaction du rapport de pré soutenance

===Semaine 12 (14/12/2015)===
===Semaine 13 (04/01/2016)===

*Amélioration du modèle

L’amélioration du modèle est réalisée en tenant compte des facteurs influent sur la qualité de la transmission.

* Utilisation d'un picoscope : appareil permettant l’acquisition sur ordinateur de plusieurs formes d'ondes.
Ainsi grâce a un pico scope utilisé à l’IRCICA j’ai pu relever de nombreux échantillons nécessaire a une étude statistique des surcoûts en énergie.

[[Fichier:Montagemulti.jpg|250px|thumb|left|'''Montage multi récepteur''']]

===Semaine 14 (11/01/2016)===

* Compilation des résultats

* Exploitation Matlab

[[Fichier:Emistbrecap.PNG]]

===Semaine 15 (18/01/2016)===

Principe de fonctionnement du récupérateur d’énergie

Le récupérateur d’énergie fonctionne grâce à un patch piezo. Ce patch est capable de produire un courent à partir de la vélocité d’une impulsion suivent la formule :

[[Fichier:Equapiezo.PNG]]

[[Fichier:Modelepizo.PNG|250px|thumb|left|'''Modèle simplifié du patch piezo''']]

Pour récupérer de l’énergie il est couplé au système suivent :

[[Fichier:montagepiezo.PNG]]

La puissance du système est définie par :

P=V*im

L’énergie s’exprime alors :

[[Fichier:Equaenergie.PNG]]

L’énergie produite par le système est donc dépendante de la tension d’alimentation V de la constante électromécanique N et du choc produit sur le patch piezo.
Une impulsion sur le capteur piezo est de la forme :

La dérivée par rapport au temps de cette impulsion est donc de la forme :

Il est donc important de « fenêtrer » la tension pour ne récupérer que la partie positive.
Ce fenêtrage ainsi que la fréquence de commutation du hacheur est assurée par un microcontrôleur.

Dans la suite de notre étude nous ne tiendrons pas compte de la consommation de celui-ci.

===Semaine 16 (25/01/2016)===

* Réflexions sur le prototypage

* Présentation du récupérateur

* Mise en place du banc de test

* Premiers relevés

[[Fichier:Montagepiezo.jpg|250px|thumb|left|'''Montage piezo''']]
[[Fichier:Patchpiezo.jpg|250px|thumb|center|'''Patch piezo''']]

===Semaine 17 (01/02/2016)===

Test de la quantité d’énergie récupérée par un patch piezo

Méthodologie :

Channel rouge : Tension aux bornes du patch piezo. Ici on observe une fenêtre de tension de 4,5ms imposée par le microcontrôleur.

Channel vert : Tension aux bornes de la capacité C1 de 220nF
[[Fichier:Diffpot.png|250px|thumb|center]]

On constate qu’un choc sur le patch piezo produit une énergie suivent la formule, E = V * N * Δw
N étant une constante électromécanique, on va faire varier V pour évaluer le gain en énergie. Cependant Δw est généré par un choc d’un stylo sur le patch il n’est donc pas uniforme.
Nous utilisons donc une méthode statistique qui consiste à retirer deux extrémum et faire la moyenne de 10 mesures.

Nous obtenons la courbe suivante :

On constate que la courbe n’est pas linéaire comme l’aurai laissé supposer la formule. En effet jusqu’à 30V elle est linéaire croissante suivent l’équation :

Puis après 30V elle devient quadratique décroissante suivent la formule :

En effet la formule E = V * N * Δw néglige les pertes. Celles-ci deviennent plus importante a chaque augmentation de la tension d’alimentation.

On obtient donc un point de fonctionnement optimal a 30V pour notre système. Ce qui impose que notre système soit équipé d’une source de tension en conséquence.

===Semaine 18 (08/02/2016)===
===Semaine 19 (15/02/2016)===
===Semaine 20 (22/02/2016)===

== Annexes ==

Consommation du STM32L4 Series : http://www.st.com/web/en/catalog/mmc/FM141/SC1169/SS1580?sc=stm32l4

Réduction de la consommation de l'Arduino : http://www.home-automation-community.com/arduino-low-power-how-to-run-atmega328p-for-a-year-on-coin-cell-battery/

Consommation Raspberry : https://www.raspberrypi.org/help/faqs/

Module BLE : http://redbearlab.com/blemini/

Accéléromètre : http://fr.farnell.com/analog-devices/adxl345bccz/accelerometre-3-axes-14lga/dp/1853935

Capteur température : http://fr.farnell.com/analog-devices/tmp36gt9z/capteur-temp-to-92-3/dp/1438760?ost=TMP36GT9Z
ou http://fr.farnell.com/stmicroelectronics/stlm20w87f/capteur-de-temperature-analog/dp/1391131

Accéléromètre + Gyroscope : http://fr.farnell.com/invensense/mpu-6050/gyroscope-accelero-6-axes-i2c/dp/1864742

Altimètre : http://fr.farnell.com/freescale-semiconductor/mpl3115a2/pressure-sensor-20-110kpa-8lga/dp/2009084?ost=MPL3115A2&categoryId=700000004367

Explications norme BLE : chapters.comsoc.org/vancouver/BTLER3.pdf

http://www.argenox.com/bluetooth-low-energy-ble-v4-0-development/library/a-ble-advertising-primer/

== Rapport de Mi-projet ==

[[Fichier:CR_Miprojet_Sultana.pdf‎ ]]

P32 Récupération d'énergie pour balise BLE

2016-02-10T15:56:01Z

Qsultana : /* Semaine 16 (25/01/2016) */

== Objectif ==

Mon projet consiste à réaliser un système électronique autonome, composé de différents capteurs et capable de recueillir et de transmettre les données mémorisées vers un système centralisé.

== Etude préalable ==

L’énergie est le point de difficulté dans la réalisation de ce projet. Chaque élément devra être choisi non seulement pour ses performances mais également pour sa faible consommation.

== Organisation générale ==

Le système est organisé autour d’une source d’énergie, d’un contrôleur, de capteurs, de mémoire et d’un protocole de communication.

On cherche à minimiser l'énergie consommée par l'ensemble du système.

[[Fichier:P32Ensemble.PNG|250px|thumb|left|'''Architecture''']]

=== Chaine de l’énergie ===

L’énergie pour ce module autonome est constituée de quatre phases importantes :

[[Fichier:P32Energie.PNG]]

==== La récupération de l'énergie dans l'environnement ====

Il existe de nombreux moyens pour récupérer de l'énergie dans l'environnement. L'objectif est de trouver les sources les plus adaptées à l'environnement de l'application recherchée.

On peut citer:

* La récupération de l'énergie par différence de température

* Les panneaux photovoltaïques

* La récupération de l'énergie des ondes radio

* La Piézoélectricité

Dans ce projet nous utiliserons la piézoélectricité, le module de récupération ayant déjà fait partie d'une étude de IRCICA précédent le projet.

==== Le stockage de l’énergie ====

Le choix du système de stockage de l'énergie constitue une partie importante de la réalisation du système.
La problématique de cette partie sera de déterminer quel type de stockage nous utiliserons : batterie, super-capacité ou un hybride et de les dimensionner.
Il faudra tenir compte des problèmes de décharge partielle influent sur la durée de vie du stockage.

==== Le management/mise en forme de l’énergie ====

L'objectif de cette partie est d'étudier la nécessité de la mise en place d'une régulation tout en préservant des contraintes de consommation très faibles.

==== L'utilisation de l'énergie mise en forme ====

On cherche à minimiser l'énergie consommée par l'ensemble du système.

=== Contrôleur ===

Le microprocesseur : il existe différents types de microprocesseurs. L'objectif est de choisir un support capable de consommer un minimum d'énergie tout en conservant une taille minimale. Nous avons déjà utilisé dans d'autres projets des micro-contrôleurs de type Arduino et Raspberry pie. Ceux-ci ont pour avantage d’être prêts à l'emploi et faciles de prise en main. On peut s’orienter également vers un contrôleur ultra low power comme le STM32L4.

{| class="wikitable centre" width="80%"
|+
|-
! scope=col |
! scope=col | Consommation
! scope=col | Facilité de développement
! scope=col | Miniaturisation
|-
| width="33%" |
<center>Arduino</center>
| width="34%" |
<center>faible à très faible</center>
| width="33%" |
<center>bonne</center>
| width="33%" |
<center>faible</center>
|-
| width="33%" |
<center>Raspberry pi</center>
| width="34%" |
<center>importante</center>
| width="34%" |
<center>très bonne</center>
| width="34%" |
<center>très faible</center>
|-
| width="33%" |
<center>Ultra low power</center>
| width="34%" |
<center>très, très faible</center>
| width="33%" |
<center>difficile</center>
| width="33%" |
<center>forte</center>
|}

=== Capteurs ===

On peut imaginer différents types de capteurs :

* Accéléromètre

* Gyroscope

* Pression atmosphérique et altitude

* Température

* GPS

=== Mémoire ===

Le système doit être autonome et donc conserver un minimum de mesures pour les cas où la connexion est impossible. La mémoire doit être dimensionnée en fonction du nombre de capteurs, l’intervalle d’acquisition et le temps maximum avant connexion au système centralisé.

=== Protocole de communication ===

Un protocole de communication : dans un premier temps, nous nous concentrons sur le protocole BLE (Bluetooth Low Energie). Ce protocole étant standardisé, il nous permettra de recueillir de la documentation et réaliser des tests de consommation rapides.

== Planning prévisionnel ==

[[Fichier:P32Gant.PNG]]

==Suivi de l'avancement du Projet==
===Semaine 1 (28/09/2015)===

* Rencontre avec Monsieur Boe et Monsieur Giraud

* Présentation du projet

* Recherche documentaire

* Etablissement du cahier des charges

===Semaine 2 (05/10/2015)===

Recherche documentaire sur la consommation estimée des différents éléments.

{| class="wikitable centre" width="80%"
|+
|-
! scope=col | '''Contrôleur'''
! scope=col | Consommation Active
! scope=col | Consommation Inactive
! scope=col | Prix
|-
| width="33%" |
<center>Arduino Pro Mini 328 </center>
| width="34%" |
<center> 7mA (1 capteur)</center>
| width="33%" |
<center>4.5µA</center>
| width="33%" |
<center>Disponible</center>
|-
| width="33%" |
<center>STM32L4 Series (STM32L476JE)</center>
| width="34%" |
<center> 100 μA/MHz</center>
| width="33%" |
<center>120 nA</center>
| width="33%" |
<center>$5</center>
|-
| width="33%" |
<center>Raspberry</center>
| width="34%" |
<center> 200mA </center>
| width="33%" |
<center>200mA</center>
| width="33%" |
<center>Disponible</center>
|}

{| class="wikitable centre" width="80%"
|+
|-
! scope=col | '''Module BLE'''
! scope=col | Consommation
! scope=col | Options d'alimentation
! scope=col | Prix
|-
| width="33%" |
<center>BLE Mini</center>
| width="34%" |
<center> 15 mA </center>
| width="33%" |
<center>3.4V à 11V VIN / 5V USB / Coin Cell Battery (2025 or 2032) / 3.7V Li-ion Battery</center>
| width="33%" |
<center>$17</center>
|}

* <s> Le système Mini Arduino/ BLE Mini me semble être un bon compromis entre facilité d’intégration, consommation d'énergie et miniaturisation du système.</s> (Choix à discuter à la réunion du Merdredi 07/10)
* Choix du module RFduino

{| class="wikitable centre" width="80%"
|+
|-
! scope=col | '''Capteurs'''
! scope=col | Modèle
! scope=col | Alimentation min/max
! scope=col | Prix
|-
| width="33%" |
<center>Température</center>
| width="34%" |
<center> TMP36GT9Z </center>
| width="33%" |
<center>2.7V/5.5V</center>
| width="33%" |
<center>1,46 €</center>
|-
| width="33%" |
<center>Accéléromètre</center>
| width="34%" |
<center> ADXL345BCCZ </center>
| width="33%" |
<center>2V/3.6V</center>
| width="33%" |
<center>5,54 €</center>
|-
| width="33%" |
<center>Gyroscope+Accéléromètre</center>
| width="34%" |
<center> MPU-6050</center>
| width="33%" |
<center>2.5V/3.6V</center>
| width="33%" |
<center>15,73 €</center>
|-
| width="33%" |
<center>Pression atmosphérique / Altitude</center>
| width="34%" |
<center> MPL3115A2 </center>
| width="33%" |
<center>1.95V/3.6V</center>
| width="33%" |
<center>2,65 €</center>
|}

* Pour minimiser les pertes on cherche a travailler avec une tension d'alimentation la plus faible possible. Je propose de travailler avec une tension d'alimentation de 3,3V (Validé à discuter à la réunion du Merdredi 07/10)

* Le système de récupération d'énergie fonctionnant sur la base d'un mouvement, j'ai choisi l'ensemble des capteur ci dessus qui me semble être adapté à l'intégration dans un système en mouvement. (Validé à discuter à la réunion du Merdredi 07/10)

* Récupération des modules RFduino, prise en main

===Semaine 3 (12/10/2015)===

* Installation des librairies

* Visualisation d'exemples

* Tests d'implantation du code source du projet P14: Aimant intelligent de la session IMA4: 2014/2015

* Optimisation du code pour la réduction de la consommation d'énergie

* Recherches sur d'autres composants dans l'optique d'une consommation toujours plus faible

{| class="wikitable centre" width="80%"
|+
|-
! scope=col | '''Capteurs'''
! scope=col | Modèle
! scope=col | Alimentation min/max
! scope=col | Prix
! scope=col | Consommation (typ/max)
|-
| width="33%" |
<center>Température</center>
| width="34%" |
<center> STLM20W87F </center>
| width="33%" |
<center>2.4V/5.5V</center>
| width="33%" |
<center> 0,775 € </center>
| width="33%" |
<center> 4.8 μA/8.0 μA </center>
|}

'''Calcul théorique de la consommation énergétique du module BLE + RFD22301'''

Mode "endormi" : ARM CPU Running Current + Output standard drive current = 4 + 0.5 = 4.5mA

Mode "acquisition": ARM CPU Running Current + Output high drive current = 5 + 4 = 9mA

Mode "transmission" : ARM CPU Running Current + Transmit Current + Output standard drive current = 4 + 0.5 + 12 = 16.5mA

http://www.rfduino.com/wp-content/uploads/2014/03/RFD22301.Data_.Sheet_.11.24.13_11.38PM.pdf

'''Code possible du mode "endormi"'''

pinMode(5, INPUT);
RFduino_pinWake(5, HIGH);

RFduino_ULPDelay(INFINITE);
if (RFduino_pinWoke(5))
{
state = ! state;
RFduinoGZLL.sendToHost(state);
}

http://forum.rfduino.com/index.php?topic=385.0

===Semaine 4 (19/10/2015)===

* Réunion du 21/10

* Réalisation de tests

* Ajustement du nombre de capteurs : dans un premier temps on utilisera le capteur de température puis l'accéléromètre

* Discussion sur le bac de test et méthodes de test : résistance de visualisation, chronométrage du temps de transmission, vitesse du processeur

* Réalisation des premiers relevés

===Semaine 5 (26/10/2015)===

* Recherche bibliographique sur les modes d'endormissement du module RFduino

* Essais de codes utilisant un mode d'endormissement plus profond

* Réalisation de graphique de l'énergie utilisée par le module lors de la transmission d'un message par le module BLE.

* Recherches sur des méthodes de programmation pour la diminution de la vitesse processeur

[[Fichier:P32Montage.jpg|250px|thumb|left|'''Montage de test''']]
[[Fichier:P32resultats.jpg|250px|thumb|center|'''Visualisation du courant consommé lors d'envoi toutes les 10ms''']]

* On visualise à l'oscilloscope des pic d'envoi et des pic d'avertissement de la balise BLE, on peut ainsi déduire la puissance nécessaire de chaque action

===Semaine 6 (02/11/2015)===

* Test de diminution de la vitesse processeur

* Réalisation de graphique démontrant l'impact de la réduction de la vitesse processeur sur l'énergie consommée et déduction d'une vitesse optimale pour notre application

* Réunion du 4/11

Définition d'objectifs : Création d'un fichier excel permettant de caractériser les coûts en énergies de chaque étapes de fonctionnement du système.

* Création d'un environnement de test "normé" ( Pour éviter les variations de mesures on réalise un banc et on applique les mêmes conditions de test pour chaque essai)

* Recherche bibliographique sur la norme BLE : recherche du temps maximum entre deux "avertissements" de la balise BLE

===Semaine 7 (09/11/2015)===
* Explication du principe de communication BLE pour l'exploitation des résultats

[[Fichier:Freq.PNG]]

Nous nous intéressons dans notre projet à "l'observateur". Cet objet peut avoir trois états : stand-by, advertising et en communication.

[[Fichier:Brod2.png]]

Dans le mode "Advertising" le système peut :

- Avertir le système récepteur de la proximité d'un capteur

- Avertir de la présence à un appareil souhaitant ce connecter

- Ce reconnecter de façon asynchrone

===Semaine 8 (16/11/2015)===

Analyse en détail d'une trame BLE

[[Fichier:Com.PNG]]

On constate que pendant la durée de la trame il y a un échange entre les deux objets appairé. On s’intéresse ici uniquement aux actions "Slave Tx". Le but étant d'identifier la durée et le courant consommé par ces actions pour obtenir des valeurs en joules.

[[Fichier:SchemaCom.PNG]]

On constate donc deux phases :

- Advertising event

- Connexion event

Nous allons essayer de retrouver et quantifié l'énergie consommé dans ces deux phases.

===Semaine 9 (23/11/2015)===

Lors de cette semaine nous avons effectué des tests en respectant une procédure de test précise. En effet les valeurs des courants que nous relevons sont très petites aussi chaque variation du montage est susceptible de perturber les valeurs.

[[Fichier:P32Conne.jpg|250px|thumb|left|'''Phase connexion''']]

[[Fichier:Avertissement.jpg|250px|thumb|center|'''Phase Advertising''']]

===Semaine 10 (30/11/2015)===

- On cherche a diminuer légèrement la consommation par des modifications logiciel :

Réduction de la puissance de la radio BLE : Diminution de la portée

Augmentation de la fréquence d'advertising : tant que la fréquence d'advetising est inférieure a cette de relevé des capteurs on s'assure que la donnée envoyée est toujours mise à jour.

[[Fichier:Pwl20-envoi.jpg|250px|thumb|left|'''Avec modification logiciel''']]

[[Fichier:Sans-pwlvl.jpg|250px|thumb|center|'''Sans modification logiciel''']]

- On concentre nos résultats dans un tableau récapitulatif en vue du dimensionnement de la batterie du système

[[Fichier:P32tbresul.PNG]]

===Semaine 11 (07/12/2015)===

Tests d'intégration de plusieurs capteur et observations des modification de la consommation des ADC et de la durée/consommation de la transmission.

Réunion de vérification des tests.

Mise en évidence de la dualité consommation d'énergie - Temps de réponse du système

En effet chaque "Advertisement" consomme une quantité d'énergie nous pouvons gérer l'espacement entre ceux-ci mais plus ce temps serra élevé plus il faudra de temps pour ce connecter à ce périphérique.

* Rédaction d'un rapport de test

* Rédaction du rapport de pré soutenance

===Semaine 12 (14/12/2015)===
===Semaine 13 (04/01/2016)===

*Amélioration du modèle

L’amélioration du modèle est réalisée en tenant compte des facteurs influent sur la qualité de la transmission.

* Utilisation d'un picoscope : appareil permettant l’acquisition sur ordinateur de plusieurs formes d'ondes.
Ainsi grâce a un pico scope utilisé à l’IRCICA j’ai pu relever de nombreux échantillons nécessaire a une étude statistique des surcoûts en énergie.

[[Fichier:Montagemulti.jpg|250px|thumb|left|'''Montage multi récepteur''']]

===Semaine 14 (11/01/2016)===

* Compilation des résultats

* Exploitation Matlab

[[Fichier:Emistbrecap.PNG]]

===Semaine 15 (18/01/2016)===

Principe de fonctionnement du récupérateur d’énergie

Le récupérateur d’énergie fonctionne grâce à un patch piezo. Ce patch est capable de produire un courent à partir de la vélocité d’une impulsion suivent la formule :

[[Fichier:Equapiezo.PNG]]

[[Fichier:Modelepizo.PNG|250px|thumb|left|'''Modèle simplifié du patch piezo''']]

Pour récupérer de l’énergie il est couplé au système suivent :

[[Fichier:montagepiezo.PNG]]

La puissance du système est définie par :

P=V*im

L’énergie s’exprime alors :

[[Fichier:Equaenergie.PNG]]

L’énergie produite par le système est donc dépendante de la tension d’alimentation V de la constante électromécanique N et du choc produit sur le patch piezo.
Une impulsion sur le capteur piezo est de la forme :

La dérivée par rapport au temps de cette impulsion est donc de la forme :

Il est donc important de « fenêtrer » la tension pour ne récupérer que la partie positive.
Ce fenêtrage ainsi que la fréquence de commutation du hacheur est assurée par un microcontrôleur.

Dans la suite de notre étude nous ne tiendrons pas compte de la consommation de celui-ci.

===Semaine 16 (25/01/2016)===

* Réflexions sur le prototypage

* Présentation du récupérateur

* Mise en place du banc de test

* Premiers relevés

[[Fichier:Montagepiezo.jpg|250px|thumb|left|'''Montage piezo''']]
[[Fichier:Patchpiezo.jpg|250px|thumb|center|'''Patch piezo''']]

===Semaine 17 (01/02/2016)===

Test de la quantité d’énergie récupérée par un patch piezo

Méthodologie :

Channel rouge : Tension aux bornes du patch piezo. Ici on observe une fenêtre de tension de 4,5ms imposée par le microcontrôleur.

Channel vert : Tension aux bornes de la capacité C1 de 220nF

[[Fichier:Diffpot.png]]

On constate qu’un choc sur le patch piezo produit une énergie suivent la formule, E = V * N * Δw
N étant une constante électromécanique, on va faire varier V pour évaluer le gain en énergie. Cependant Δw est généré par un choc d’un stylo sur le patch il n’est donc pas uniforme.
Nous utilisons donc une méthode statistique qui consiste à retirer deux extrémum et faire la moyenne de 10 mesures.

Nous obtenons la courbe suivante :

On constate que la courbe n’est pas linéaire comme l’aurai laissé supposer la formule. En effet jusqu’à 30V elle est linéaire croissante suivent l’équation :

Puis après 30V elle devient quadratique décroissante suivent la formule :

En effet la formule E = V * N * Δw néglige les pertes. Celles-ci deviennent plus importante a chaque augmentation de la tension d’alimentation.

On obtient donc un point de fonctionnement optimal a 30V pour notre système. Ce qui impose que notre système soit équipé d’une source de tension en conséquence.

===Semaine 18 (08/02/2016)===
===Semaine 19 (15/02/2016)===
===Semaine 20 (22/02/2016)===

== Annexes ==

Consommation du STM32L4 Series : http://www.st.com/web/en/catalog/mmc/FM141/SC1169/SS1580?sc=stm32l4

Réduction de la consommation de l'Arduino : http://www.home-automation-community.com/arduino-low-power-how-to-run-atmega328p-for-a-year-on-coin-cell-battery/

Consommation Raspberry : https://www.raspberrypi.org/help/faqs/

Module BLE : http://redbearlab.com/blemini/

Accéléromètre : http://fr.farnell.com/analog-devices/adxl345bccz/accelerometre-3-axes-14lga/dp/1853935

Capteur température : http://fr.farnell.com/analog-devices/tmp36gt9z/capteur-temp-to-92-3/dp/1438760?ost=TMP36GT9Z
ou http://fr.farnell.com/stmicroelectronics/stlm20w87f/capteur-de-temperature-analog/dp/1391131

Accéléromètre + Gyroscope : http://fr.farnell.com/invensense/mpu-6050/gyroscope-accelero-6-axes-i2c/dp/1864742

Altimètre : http://fr.farnell.com/freescale-semiconductor/mpl3115a2/pressure-sensor-20-110kpa-8lga/dp/2009084?ost=MPL3115A2&categoryId=700000004367

Explications norme BLE : chapters.comsoc.org/vancouver/BTLER3.pdf

http://www.argenox.com/bluetooth-low-energy-ble-v4-0-development/library/a-ble-advertising-primer/

== Rapport de Mi-projet ==

[[Fichier:CR_Miprojet_Sultana.pdf‎ ]]

Fichier:Patchpiezo.jpg

2016-02-10T15:55:07Z

Qsultana : P32 : Patch piezo

P32 : Patch piezo

P32 Récupération d'énergie pour balise BLE

2016-02-10T15:54:22Z

Qsultana : /* Semaine 16 (25/01/2016) */

== Objectif ==

Mon projet consiste à réaliser un système électronique autonome, composé de différents capteurs et capable de recueillir et de transmettre les données mémorisées vers un système centralisé.

== Etude préalable ==

L’énergie est le point de difficulté dans la réalisation de ce projet. Chaque élément devra être choisi non seulement pour ses performances mais également pour sa faible consommation.

== Organisation générale ==

Le système est organisé autour d’une source d’énergie, d’un contrôleur, de capteurs, de mémoire et d’un protocole de communication.

On cherche à minimiser l'énergie consommée par l'ensemble du système.

[[Fichier:P32Ensemble.PNG|250px|thumb|left|'''Architecture''']]

=== Chaine de l’énergie ===

L’énergie pour ce module autonome est constituée de quatre phases importantes :

[[Fichier:P32Energie.PNG]]

==== La récupération de l'énergie dans l'environnement ====

Il existe de nombreux moyens pour récupérer de l'énergie dans l'environnement. L'objectif est de trouver les sources les plus adaptées à l'environnement de l'application recherchée.

On peut citer:

* La récupération de l'énergie par différence de température

* Les panneaux photovoltaïques

* La récupération de l'énergie des ondes radio

* La Piézoélectricité

Dans ce projet nous utiliserons la piézoélectricité, le module de récupération ayant déjà fait partie d'une étude de IRCICA précédent le projet.

==== Le stockage de l’énergie ====

Le choix du système de stockage de l'énergie constitue une partie importante de la réalisation du système.
La problématique de cette partie sera de déterminer quel type de stockage nous utiliserons : batterie, super-capacité ou un hybride et de les dimensionner.
Il faudra tenir compte des problèmes de décharge partielle influent sur la durée de vie du stockage.

==== Le management/mise en forme de l’énergie ====

L'objectif de cette partie est d'étudier la nécessité de la mise en place d'une régulation tout en préservant des contraintes de consommation très faibles.

==== L'utilisation de l'énergie mise en forme ====

On cherche à minimiser l'énergie consommée par l'ensemble du système.

=== Contrôleur ===

Le microprocesseur : il existe différents types de microprocesseurs. L'objectif est de choisir un support capable de consommer un minimum d'énergie tout en conservant une taille minimale. Nous avons déjà utilisé dans d'autres projets des micro-contrôleurs de type Arduino et Raspberry pie. Ceux-ci ont pour avantage d’être prêts à l'emploi et faciles de prise en main. On peut s’orienter également vers un contrôleur ultra low power comme le STM32L4.

{| class="wikitable centre" width="80%"
|+
|-
! scope=col |
! scope=col | Consommation
! scope=col | Facilité de développement
! scope=col | Miniaturisation
|-
| width="33%" |
<center>Arduino</center>
| width="34%" |
<center>faible à très faible</center>
| width="33%" |
<center>bonne</center>
| width="33%" |
<center>faible</center>
|-
| width="33%" |
<center>Raspberry pi</center>
| width="34%" |
<center>importante</center>
| width="34%" |
<center>très bonne</center>
| width="34%" |
<center>très faible</center>
|-
| width="33%" |
<center>Ultra low power</center>
| width="34%" |
<center>très, très faible</center>
| width="33%" |
<center>difficile</center>
| width="33%" |
<center>forte</center>
|}

=== Capteurs ===

On peut imaginer différents types de capteurs :

* Accéléromètre

* Gyroscope

* Pression atmosphérique et altitude

* Température

* GPS

=== Mémoire ===

Le système doit être autonome et donc conserver un minimum de mesures pour les cas où la connexion est impossible. La mémoire doit être dimensionnée en fonction du nombre de capteurs, l’intervalle d’acquisition et le temps maximum avant connexion au système centralisé.

=== Protocole de communication ===

Un protocole de communication : dans un premier temps, nous nous concentrons sur le protocole BLE (Bluetooth Low Energie). Ce protocole étant standardisé, il nous permettra de recueillir de la documentation et réaliser des tests de consommation rapides.

== Planning prévisionnel ==

[[Fichier:P32Gant.PNG]]

==Suivi de l'avancement du Projet==
===Semaine 1 (28/09/2015)===

* Rencontre avec Monsieur Boe et Monsieur Giraud

* Présentation du projet

* Recherche documentaire

* Etablissement du cahier des charges

===Semaine 2 (05/10/2015)===

Recherche documentaire sur la consommation estimée des différents éléments.

{| class="wikitable centre" width="80%"
|+
|-
! scope=col | '''Contrôleur'''
! scope=col | Consommation Active
! scope=col | Consommation Inactive
! scope=col | Prix
|-
| width="33%" |
<center>Arduino Pro Mini 328 </center>
| width="34%" |
<center> 7mA (1 capteur)</center>
| width="33%" |
<center>4.5µA</center>
| width="33%" |
<center>Disponible</center>
|-
| width="33%" |
<center>STM32L4 Series (STM32L476JE)</center>
| width="34%" |
<center> 100 μA/MHz</center>
| width="33%" |
<center>120 nA</center>
| width="33%" |
<center>$5</center>
|-
| width="33%" |
<center>Raspberry</center>
| width="34%" |
<center> 200mA </center>
| width="33%" |
<center>200mA</center>
| width="33%" |
<center>Disponible</center>
|}

{| class="wikitable centre" width="80%"
|+
|-
! scope=col | '''Module BLE'''
! scope=col | Consommation
! scope=col | Options d'alimentation
! scope=col | Prix
|-
| width="33%" |
<center>BLE Mini</center>
| width="34%" |
<center> 15 mA </center>
| width="33%" |
<center>3.4V à 11V VIN / 5V USB / Coin Cell Battery (2025 or 2032) / 3.7V Li-ion Battery</center>
| width="33%" |
<center>$17</center>
|}

* <s> Le système Mini Arduino/ BLE Mini me semble être un bon compromis entre facilité d’intégration, consommation d'énergie et miniaturisation du système.</s> (Choix à discuter à la réunion du Merdredi 07/10)
* Choix du module RFduino

{| class="wikitable centre" width="80%"
|+
|-
! scope=col | '''Capteurs'''
! scope=col | Modèle
! scope=col | Alimentation min/max
! scope=col | Prix
|-
| width="33%" |
<center>Température</center>
| width="34%" |
<center> TMP36GT9Z </center>
| width="33%" |
<center>2.7V/5.5V</center>
| width="33%" |
<center>1,46 €</center>
|-
| width="33%" |
<center>Accéléromètre</center>
| width="34%" |
<center> ADXL345BCCZ </center>
| width="33%" |
<center>2V/3.6V</center>
| width="33%" |
<center>5,54 €</center>
|-
| width="33%" |
<center>Gyroscope+Accéléromètre</center>
| width="34%" |
<center> MPU-6050</center>
| width="33%" |
<center>2.5V/3.6V</center>
| width="33%" |
<center>15,73 €</center>
|-
| width="33%" |
<center>Pression atmosphérique / Altitude</center>
| width="34%" |
<center> MPL3115A2 </center>
| width="33%" |
<center>1.95V/3.6V</center>
| width="33%" |
<center>2,65 €</center>
|}

* Pour minimiser les pertes on cherche a travailler avec une tension d'alimentation la plus faible possible. Je propose de travailler avec une tension d'alimentation de 3,3V (Validé à discuter à la réunion du Merdredi 07/10)

* Le système de récupération d'énergie fonctionnant sur la base d'un mouvement, j'ai choisi l'ensemble des capteur ci dessus qui me semble être adapté à l'intégration dans un système en mouvement. (Validé à discuter à la réunion du Merdredi 07/10)

* Récupération des modules RFduino, prise en main

===Semaine 3 (12/10/2015)===

* Installation des librairies

* Visualisation d'exemples

* Tests d'implantation du code source du projet P14: Aimant intelligent de la session IMA4: 2014/2015

* Optimisation du code pour la réduction de la consommation d'énergie

* Recherches sur d'autres composants dans l'optique d'une consommation toujours plus faible

{| class="wikitable centre" width="80%"
|+
|-
! scope=col | '''Capteurs'''
! scope=col | Modèle
! scope=col | Alimentation min/max
! scope=col | Prix
! scope=col | Consommation (typ/max)
|-
| width="33%" |
<center>Température</center>
| width="34%" |
<center> STLM20W87F </center>
| width="33%" |
<center>2.4V/5.5V</center>
| width="33%" |
<center> 0,775 € </center>
| width="33%" |
<center> 4.8 μA/8.0 μA </center>
|}

'''Calcul théorique de la consommation énergétique du module BLE + RFD22301'''

Mode "endormi" : ARM CPU Running Current + Output standard drive current = 4 + 0.5 = 4.5mA

Mode "acquisition": ARM CPU Running Current + Output high drive current = 5 + 4 = 9mA

Mode "transmission" : ARM CPU Running Current + Transmit Current + Output standard drive current = 4 + 0.5 + 12 = 16.5mA

http://www.rfduino.com/wp-content/uploads/2014/03/RFD22301.Data_.Sheet_.11.24.13_11.38PM.pdf

'''Code possible du mode "endormi"'''

pinMode(5, INPUT);
RFduino_pinWake(5, HIGH);

RFduino_ULPDelay(INFINITE);
if (RFduino_pinWoke(5))
{
state = ! state;
RFduinoGZLL.sendToHost(state);
}

http://forum.rfduino.com/index.php?topic=385.0

===Semaine 4 (19/10/2015)===

* Réunion du 21/10

* Réalisation de tests

* Ajustement du nombre de capteurs : dans un premier temps on utilisera le capteur de température puis l'accéléromètre

* Discussion sur le bac de test et méthodes de test : résistance de visualisation, chronométrage du temps de transmission, vitesse du processeur

* Réalisation des premiers relevés

===Semaine 5 (26/10/2015)===

* Recherche bibliographique sur les modes d'endormissement du module RFduino

* Essais de codes utilisant un mode d'endormissement plus profond

* Réalisation de graphique de l'énergie utilisée par le module lors de la transmission d'un message par le module BLE.

* Recherches sur des méthodes de programmation pour la diminution de la vitesse processeur

[[Fichier:P32Montage.jpg|250px|thumb|left|'''Montage de test''']]
[[Fichier:P32resultats.jpg|250px|thumb|center|'''Visualisation du courant consommé lors d'envoi toutes les 10ms''']]

* On visualise à l'oscilloscope des pic d'envoi et des pic d'avertissement de la balise BLE, on peut ainsi déduire la puissance nécessaire de chaque action

===Semaine 6 (02/11/2015)===

* Test de diminution de la vitesse processeur

* Réalisation de graphique démontrant l'impact de la réduction de la vitesse processeur sur l'énergie consommée et déduction d'une vitesse optimale pour notre application

* Réunion du 4/11

Définition d'objectifs : Création d'un fichier excel permettant de caractériser les coûts en énergies de chaque étapes de fonctionnement du système.

* Création d'un environnement de test "normé" ( Pour éviter les variations de mesures on réalise un banc et on applique les mêmes conditions de test pour chaque essai)

* Recherche bibliographique sur la norme BLE : recherche du temps maximum entre deux "avertissements" de la balise BLE

===Semaine 7 (09/11/2015)===
* Explication du principe de communication BLE pour l'exploitation des résultats

[[Fichier:Freq.PNG]]

Nous nous intéressons dans notre projet à "l'observateur". Cet objet peut avoir trois états : stand-by, advertising et en communication.

[[Fichier:Brod2.png]]

Dans le mode "Advertising" le système peut :

- Avertir le système récepteur de la proximité d'un capteur

- Avertir de la présence à un appareil souhaitant ce connecter

- Ce reconnecter de façon asynchrone

===Semaine 8 (16/11/2015)===

Analyse en détail d'une trame BLE

[[Fichier:Com.PNG]]

On constate que pendant la durée de la trame il y a un échange entre les deux objets appairé. On s’intéresse ici uniquement aux actions "Slave Tx". Le but étant d'identifier la durée et le courant consommé par ces actions pour obtenir des valeurs en joules.

[[Fichier:SchemaCom.PNG]]

On constate donc deux phases :

- Advertising event

- Connexion event

Nous allons essayer de retrouver et quantifié l'énergie consommé dans ces deux phases.

===Semaine 9 (23/11/2015)===

Lors de cette semaine nous avons effectué des tests en respectant une procédure de test précise. En effet les valeurs des courants que nous relevons sont très petites aussi chaque variation du montage est susceptible de perturber les valeurs.

[[Fichier:P32Conne.jpg|250px|thumb|left|'''Phase connexion''']]

[[Fichier:Avertissement.jpg|250px|thumb|center|'''Phase Advertising''']]

===Semaine 10 (30/11/2015)===

- On cherche a diminuer légèrement la consommation par des modifications logiciel :

Réduction de la puissance de la radio BLE : Diminution de la portée

Augmentation de la fréquence d'advertising : tant que la fréquence d'advetising est inférieure a cette de relevé des capteurs on s'assure que la donnée envoyée est toujours mise à jour.

[[Fichier:Pwl20-envoi.jpg|250px|thumb|left|'''Avec modification logiciel''']]

[[Fichier:Sans-pwlvl.jpg|250px|thumb|center|'''Sans modification logiciel''']]

- On concentre nos résultats dans un tableau récapitulatif en vue du dimensionnement de la batterie du système

[[Fichier:P32tbresul.PNG]]

===Semaine 11 (07/12/2015)===

Tests d'intégration de plusieurs capteur et observations des modification de la consommation des ADC et de la durée/consommation de la transmission.

Réunion de vérification des tests.

Mise en évidence de la dualité consommation d'énergie - Temps de réponse du système

En effet chaque "Advertisement" consomme une quantité d'énergie nous pouvons gérer l'espacement entre ceux-ci mais plus ce temps serra élevé plus il faudra de temps pour ce connecter à ce périphérique.

* Rédaction d'un rapport de test

* Rédaction du rapport de pré soutenance

===Semaine 12 (14/12/2015)===
===Semaine 13 (04/01/2016)===

*Amélioration du modèle

L’amélioration du modèle est réalisée en tenant compte des facteurs influent sur la qualité de la transmission.

* Utilisation d'un picoscope : appareil permettant l’acquisition sur ordinateur de plusieurs formes d'ondes.
Ainsi grâce a un pico scope utilisé à l’IRCICA j’ai pu relever de nombreux échantillons nécessaire a une étude statistique des surcoûts en énergie.

[[Fichier:Montagemulti.jpg|250px|thumb|left|'''Montage multi récepteur''']]

===Semaine 14 (11/01/2016)===

* Compilation des résultats

* Exploitation Matlab

[[Fichier:Emistbrecap.PNG]]

===Semaine 15 (18/01/2016)===

Principe de fonctionnement du récupérateur d’énergie

Le récupérateur d’énergie fonctionne grâce à un patch piezo. Ce patch est capable de produire un courent à partir de la vélocité d’une impulsion suivent la formule :

[[Fichier:Equapiezo.PNG]]

[[Fichier:Modelepizo.PNG|250px|thumb|left|'''Modèle simplifié du patch piezo''']]

Pour récupérer de l’énergie il est couplé au système suivent :

[[Fichier:montagepiezo.PNG]]

La puissance du système est définie par :

P=V*im

L’énergie s’exprime alors :

[[Fichier:Equaenergie.PNG]]

L’énergie produite par le système est donc dépendante de la tension d’alimentation V de la constante électromécanique N et du choc produit sur le patch piezo.
Une impulsion sur le capteur piezo est de la forme :

La dérivée par rapport au temps de cette impulsion est donc de la forme :

Il est donc important de « fenêtrer » la tension pour ne récupérer que la partie positive.
Ce fenêtrage ainsi que la fréquence de commutation du hacheur est assurée par un microcontrôleur.

Dans la suite de notre étude nous ne tiendrons pas compte de la consommation de celui-ci.

===Semaine 16 (25/01/2016)===

* Réflexions sur le prototypage

* Présentation du récupérateur

* Mise en place du banc de test

* Premiers relevés

[[Fichier:Montagepiezo.jpg|250px|thumb|left|'''Montage piezo''']]

===Semaine 17 (01/02/2016)===

Test de la quantité d’énergie récupérée par un patch piezo

Méthodologie :

Channel rouge : Tension aux bornes du patch piezo. Ici on observe une fenêtre de tension de 4,5ms imposée par le microcontrôleur.

Channel vert : Tension aux bornes de la capacité C1 de 220nF

[[Fichier:Diffpot.png]]

On constate qu’un choc sur le patch piezo produit une énergie suivent la formule, E = V * N * Δw
N étant une constante électromécanique, on va faire varier V pour évaluer le gain en énergie. Cependant Δw est généré par un choc d’un stylo sur le patch il n’est donc pas uniforme.
Nous utilisons donc une méthode statistique qui consiste à retirer deux extrémum et faire la moyenne de 10 mesures.

Nous obtenons la courbe suivante :

On constate que la courbe n’est pas linéaire comme l’aurai laissé supposer la formule. En effet jusqu’à 30V elle est linéaire croissante suivent l’équation :

Puis après 30V elle devient quadratique décroissante suivent la formule :

En effet la formule E = V * N * Δw néglige les pertes. Celles-ci deviennent plus importante a chaque augmentation de la tension d’alimentation.

On obtient donc un point de fonctionnement optimal a 30V pour notre système. Ce qui impose que notre système soit équipé d’une source de tension en conséquence.

===Semaine 18 (08/02/2016)===
===Semaine 19 (15/02/2016)===
===Semaine 20 (22/02/2016)===

== Annexes ==

Consommation du STM32L4 Series : http://www.st.com/web/en/catalog/mmc/FM141/SC1169/SS1580?sc=stm32l4

Réduction de la consommation de l'Arduino : http://www.home-automation-community.com/arduino-low-power-how-to-run-atmega328p-for-a-year-on-coin-cell-battery/

Consommation Raspberry : https://www.raspberrypi.org/help/faqs/

Module BLE : http://redbearlab.com/blemini/

Accéléromètre : http://fr.farnell.com/analog-devices/adxl345bccz/accelerometre-3-axes-14lga/dp/1853935

Capteur température : http://fr.farnell.com/analog-devices/tmp36gt9z/capteur-temp-to-92-3/dp/1438760?ost=TMP36GT9Z
ou http://fr.farnell.com/stmicroelectronics/stlm20w87f/capteur-de-temperature-analog/dp/1391131

Accéléromètre + Gyroscope : http://fr.farnell.com/invensense/mpu-6050/gyroscope-accelero-6-axes-i2c/dp/1864742

Altimètre : http://fr.farnell.com/freescale-semiconductor/mpl3115a2/pressure-sensor-20-110kpa-8lga/dp/2009084?ost=MPL3115A2&categoryId=700000004367

Explications norme BLE : chapters.comsoc.org/vancouver/BTLER3.pdf

http://www.argenox.com/bluetooth-low-energy-ble-v4-0-development/library/a-ble-advertising-primer/

== Rapport de Mi-projet ==

[[Fichier:CR_Miprojet_Sultana.pdf‎ ]]

P32 Récupération d'énergie pour balise BLE

2016-02-10T15:52:37Z

Qsultana : /* Semaine 14 (11/01/2016) */

== Objectif ==

Mon projet consiste à réaliser un système électronique autonome, composé de différents capteurs et capable de recueillir et de transmettre les données mémorisées vers un système centralisé.

== Etude préalable ==

L’énergie est le point de difficulté dans la réalisation de ce projet. Chaque élément devra être choisi non seulement pour ses performances mais également pour sa faible consommation.

== Organisation générale ==

Le système est organisé autour d’une source d’énergie, d’un contrôleur, de capteurs, de mémoire et d’un protocole de communication.

On cherche à minimiser l'énergie consommée par l'ensemble du système.

[[Fichier:P32Ensemble.PNG|250px|thumb|left|'''Architecture''']]

=== Chaine de l’énergie ===

L’énergie pour ce module autonome est constituée de quatre phases importantes :

[[Fichier:P32Energie.PNG]]

==== La récupération de l'énergie dans l'environnement ====

Il existe de nombreux moyens pour récupérer de l'énergie dans l'environnement. L'objectif est de trouver les sources les plus adaptées à l'environnement de l'application recherchée.

On peut citer:

* La récupération de l'énergie par différence de température

* Les panneaux photovoltaïques

* La récupération de l'énergie des ondes radio

* La Piézoélectricité

Dans ce projet nous utiliserons la piézoélectricité, le module de récupération ayant déjà fait partie d'une étude de IRCICA précédent le projet.

==== Le stockage de l’énergie ====

Le choix du système de stockage de l'énergie constitue une partie importante de la réalisation du système.
La problématique de cette partie sera de déterminer quel type de stockage nous utiliserons : batterie, super-capacité ou un hybride et de les dimensionner.
Il faudra tenir compte des problèmes de décharge partielle influent sur la durée de vie du stockage.

==== Le management/mise en forme de l’énergie ====

L'objectif de cette partie est d'étudier la nécessité de la mise en place d'une régulation tout en préservant des contraintes de consommation très faibles.

==== L'utilisation de l'énergie mise en forme ====

On cherche à minimiser l'énergie consommée par l'ensemble du système.

=== Contrôleur ===

Le microprocesseur : il existe différents types de microprocesseurs. L'objectif est de choisir un support capable de consommer un minimum d'énergie tout en conservant une taille minimale. Nous avons déjà utilisé dans d'autres projets des micro-contrôleurs de type Arduino et Raspberry pie. Ceux-ci ont pour avantage d’être prêts à l'emploi et faciles de prise en main. On peut s’orienter également vers un contrôleur ultra low power comme le STM32L4.

{| class="wikitable centre" width="80%"
|+
|-
! scope=col |
! scope=col | Consommation
! scope=col | Facilité de développement
! scope=col | Miniaturisation
|-
| width="33%" |
<center>Arduino</center>
| width="34%" |
<center>faible à très faible</center>
| width="33%" |
<center>bonne</center>
| width="33%" |
<center>faible</center>
|-
| width="33%" |
<center>Raspberry pi</center>
| width="34%" |
<center>importante</center>
| width="34%" |
<center>très bonne</center>
| width="34%" |
<center>très faible</center>
|-
| width="33%" |
<center>Ultra low power</center>
| width="34%" |
<center>très, très faible</center>
| width="33%" |
<center>difficile</center>
| width="33%" |
<center>forte</center>
|}

=== Capteurs ===

On peut imaginer différents types de capteurs :

* Accéléromètre

* Gyroscope

* Pression atmosphérique et altitude

* Température

* GPS

=== Mémoire ===

Le système doit être autonome et donc conserver un minimum de mesures pour les cas où la connexion est impossible. La mémoire doit être dimensionnée en fonction du nombre de capteurs, l’intervalle d’acquisition et le temps maximum avant connexion au système centralisé.

=== Protocole de communication ===

Un protocole de communication : dans un premier temps, nous nous concentrons sur le protocole BLE (Bluetooth Low Energie). Ce protocole étant standardisé, il nous permettra de recueillir de la documentation et réaliser des tests de consommation rapides.

== Planning prévisionnel ==

[[Fichier:P32Gant.PNG]]

==Suivi de l'avancement du Projet==
===Semaine 1 (28/09/2015)===

* Rencontre avec Monsieur Boe et Monsieur Giraud

* Présentation du projet

* Recherche documentaire

* Etablissement du cahier des charges

===Semaine 2 (05/10/2015)===

Recherche documentaire sur la consommation estimée des différents éléments.

{| class="wikitable centre" width="80%"
|+
|-
! scope=col | '''Contrôleur'''
! scope=col | Consommation Active
! scope=col | Consommation Inactive
! scope=col | Prix
|-
| width="33%" |
<center>Arduino Pro Mini 328 </center>
| width="34%" |
<center> 7mA (1 capteur)</center>
| width="33%" |
<center>4.5µA</center>
| width="33%" |
<center>Disponible</center>
|-
| width="33%" |
<center>STM32L4 Series (STM32L476JE)</center>
| width="34%" |
<center> 100 μA/MHz</center>
| width="33%" |
<center>120 nA</center>
| width="33%" |
<center>$5</center>
|-
| width="33%" |
<center>Raspberry</center>
| width="34%" |
<center> 200mA </center>
| width="33%" |
<center>200mA</center>
| width="33%" |
<center>Disponible</center>
|}

{| class="wikitable centre" width="80%"
|+
|-
! scope=col | '''Module BLE'''
! scope=col | Consommation
! scope=col | Options d'alimentation
! scope=col | Prix
|-
| width="33%" |
<center>BLE Mini</center>
| width="34%" |
<center> 15 mA </center>
| width="33%" |
<center>3.4V à 11V VIN / 5V USB / Coin Cell Battery (2025 or 2032) / 3.7V Li-ion Battery</center>
| width="33%" |
<center>$17</center>
|}

* <s> Le système Mini Arduino/ BLE Mini me semble être un bon compromis entre facilité d’intégration, consommation d'énergie et miniaturisation du système.</s> (Choix à discuter à la réunion du Merdredi 07/10)
* Choix du module RFduino

{| class="wikitable centre" width="80%"
|+
|-
! scope=col | '''Capteurs'''
! scope=col | Modèle
! scope=col | Alimentation min/max
! scope=col | Prix
|-
| width="33%" |
<center>Température</center>
| width="34%" |
<center> TMP36GT9Z </center>
| width="33%" |
<center>2.7V/5.5V</center>
| width="33%" |
<center>1,46 €</center>
|-
| width="33%" |
<center>Accéléromètre</center>
| width="34%" |
<center> ADXL345BCCZ </center>
| width="33%" |
<center>2V/3.6V</center>
| width="33%" |
<center>5,54 €</center>
|-
| width="33%" |
<center>Gyroscope+Accéléromètre</center>
| width="34%" |
<center> MPU-6050</center>
| width="33%" |
<center>2.5V/3.6V</center>
| width="33%" |
<center>15,73 €</center>
|-
| width="33%" |
<center>Pression atmosphérique / Altitude</center>
| width="34%" |
<center> MPL3115A2 </center>
| width="33%" |
<center>1.95V/3.6V</center>
| width="33%" |
<center>2,65 €</center>
|}

* Pour minimiser les pertes on cherche a travailler avec une tension d'alimentation la plus faible possible. Je propose de travailler avec une tension d'alimentation de 3,3V (Validé à discuter à la réunion du Merdredi 07/10)

* Le système de récupération d'énergie fonctionnant sur la base d'un mouvement, j'ai choisi l'ensemble des capteur ci dessus qui me semble être adapté à l'intégration dans un système en mouvement. (Validé à discuter à la réunion du Merdredi 07/10)

* Récupération des modules RFduino, prise en main

===Semaine 3 (12/10/2015)===

* Installation des librairies

* Visualisation d'exemples

* Tests d'implantation du code source du projet P14: Aimant intelligent de la session IMA4: 2014/2015

* Optimisation du code pour la réduction de la consommation d'énergie

* Recherches sur d'autres composants dans l'optique d'une consommation toujours plus faible

{| class="wikitable centre" width="80%"
|+
|-
! scope=col | '''Capteurs'''
! scope=col | Modèle
! scope=col | Alimentation min/max
! scope=col | Prix
! scope=col | Consommation (typ/max)
|-
| width="33%" |
<center>Température</center>
| width="34%" |
<center> STLM20W87F </center>
| width="33%" |
<center>2.4V/5.5V</center>
| width="33%" |
<center> 0,775 € </center>
| width="33%" |
<center> 4.8 μA/8.0 μA </center>
|}

'''Calcul théorique de la consommation énergétique du module BLE + RFD22301'''

Mode "endormi" : ARM CPU Running Current + Output standard drive current = 4 + 0.5 = 4.5mA

Mode "acquisition": ARM CPU Running Current + Output high drive current = 5 + 4 = 9mA

Mode "transmission" : ARM CPU Running Current + Transmit Current + Output standard drive current = 4 + 0.5 + 12 = 16.5mA

http://www.rfduino.com/wp-content/uploads/2014/03/RFD22301.Data_.Sheet_.11.24.13_11.38PM.pdf

'''Code possible du mode "endormi"'''

pinMode(5, INPUT);
RFduino_pinWake(5, HIGH);

RFduino_ULPDelay(INFINITE);
if (RFduino_pinWoke(5))
{
state = ! state;
RFduinoGZLL.sendToHost(state);
}

http://forum.rfduino.com/index.php?topic=385.0

===Semaine 4 (19/10/2015)===

* Réunion du 21/10

* Réalisation de tests

* Ajustement du nombre de capteurs : dans un premier temps on utilisera le capteur de température puis l'accéléromètre

* Discussion sur le bac de test et méthodes de test : résistance de visualisation, chronométrage du temps de transmission, vitesse du processeur

* Réalisation des premiers relevés

===Semaine 5 (26/10/2015)===

* Recherche bibliographique sur les modes d'endormissement du module RFduino

* Essais de codes utilisant un mode d'endormissement plus profond

* Réalisation de graphique de l'énergie utilisée par le module lors de la transmission d'un message par le module BLE.

* Recherches sur des méthodes de programmation pour la diminution de la vitesse processeur

[[Fichier:P32Montage.jpg|250px|thumb|left|'''Montage de test''']]
[[Fichier:P32resultats.jpg|250px|thumb|center|'''Visualisation du courant consommé lors d'envoi toutes les 10ms''']]

* On visualise à l'oscilloscope des pic d'envoi et des pic d'avertissement de la balise BLE, on peut ainsi déduire la puissance nécessaire de chaque action

===Semaine 6 (02/11/2015)===

* Test de diminution de la vitesse processeur

* Réalisation de graphique démontrant l'impact de la réduction de la vitesse processeur sur l'énergie consommée et déduction d'une vitesse optimale pour notre application

* Réunion du 4/11

Définition d'objectifs : Création d'un fichier excel permettant de caractériser les coûts en énergies de chaque étapes de fonctionnement du système.

* Création d'un environnement de test "normé" ( Pour éviter les variations de mesures on réalise un banc et on applique les mêmes conditions de test pour chaque essai)

* Recherche bibliographique sur la norme BLE : recherche du temps maximum entre deux "avertissements" de la balise BLE

===Semaine 7 (09/11/2015)===
* Explication du principe de communication BLE pour l'exploitation des résultats

[[Fichier:Freq.PNG]]

Nous nous intéressons dans notre projet à "l'observateur". Cet objet peut avoir trois états : stand-by, advertising et en communication.

[[Fichier:Brod2.png]]

Dans le mode "Advertising" le système peut :

- Avertir le système récepteur de la proximité d'un capteur

- Avertir de la présence à un appareil souhaitant ce connecter

- Ce reconnecter de façon asynchrone

===Semaine 8 (16/11/2015)===

Analyse en détail d'une trame BLE

[[Fichier:Com.PNG]]

On constate que pendant la durée de la trame il y a un échange entre les deux objets appairé. On s’intéresse ici uniquement aux actions "Slave Tx". Le but étant d'identifier la durée et le courant consommé par ces actions pour obtenir des valeurs en joules.

[[Fichier:SchemaCom.PNG]]

On constate donc deux phases :

- Advertising event

- Connexion event

Nous allons essayer de retrouver et quantifié l'énergie consommé dans ces deux phases.

===Semaine 9 (23/11/2015)===

Lors de cette semaine nous avons effectué des tests en respectant une procédure de test précise. En effet les valeurs des courants que nous relevons sont très petites aussi chaque variation du montage est susceptible de perturber les valeurs.

[[Fichier:P32Conne.jpg|250px|thumb|left|'''Phase connexion''']]

[[Fichier:Avertissement.jpg|250px|thumb|center|'''Phase Advertising''']]

===Semaine 10 (30/11/2015)===

- On cherche a diminuer légèrement la consommation par des modifications logiciel :

Réduction de la puissance de la radio BLE : Diminution de la portée

Augmentation de la fréquence d'advertising : tant que la fréquence d'advetising est inférieure a cette de relevé des capteurs on s'assure que la donnée envoyée est toujours mise à jour.

[[Fichier:Pwl20-envoi.jpg|250px|thumb|left|'''Avec modification logiciel''']]

[[Fichier:Sans-pwlvl.jpg|250px|thumb|center|'''Sans modification logiciel''']]

- On concentre nos résultats dans un tableau récapitulatif en vue du dimensionnement de la batterie du système

[[Fichier:P32tbresul.PNG]]

===Semaine 11 (07/12/2015)===

Tests d'intégration de plusieurs capteur et observations des modification de la consommation des ADC et de la durée/consommation de la transmission.

Réunion de vérification des tests.

Mise en évidence de la dualité consommation d'énergie - Temps de réponse du système

En effet chaque "Advertisement" consomme une quantité d'énergie nous pouvons gérer l'espacement entre ceux-ci mais plus ce temps serra élevé plus il faudra de temps pour ce connecter à ce périphérique.

* Rédaction d'un rapport de test

* Rédaction du rapport de pré soutenance

===Semaine 12 (14/12/2015)===
===Semaine 13 (04/01/2016)===

*Amélioration du modèle

L’amélioration du modèle est réalisée en tenant compte des facteurs influent sur la qualité de la transmission.

* Utilisation d'un picoscope : appareil permettant l’acquisition sur ordinateur de plusieurs formes d'ondes.
Ainsi grâce a un pico scope utilisé à l’IRCICA j’ai pu relever de nombreux échantillons nécessaire a une étude statistique des surcoûts en énergie.

[[Fichier:Montagemulti.jpg|250px|thumb|left|'''Montage multi récepteur''']]

===Semaine 14 (11/01/2016)===

* Compilation des résultats

* Exploitation Matlab

[[Fichier:Emistbrecap.PNG]]

===Semaine 15 (18/01/2016)===

Principe de fonctionnement du récupérateur d’énergie

Le récupérateur d’énergie fonctionne grâce à un patch piezo. Ce patch est capable de produire un courent à partir de la vélocité d’une impulsion suivent la formule :

[[Fichier:Equapiezo.PNG]]

[[Fichier:Modelepizo.PNG|250px|thumb|left|'''Modèle simplifié du patch piezo''']]

Pour récupérer de l’énergie il est couplé au système suivent :

[[Fichier:montagepiezo.PNG]]

La puissance du système est définie par :

P=V*im

L’énergie s’exprime alors :

[[Fichier:Equaenergie.PNG]]

L’énergie produite par le système est donc dépendante de la tension d’alimentation V de la constante électromécanique N et du choc produit sur le patch piezo.
Une impulsion sur le capteur piezo est de la forme :

La dérivée par rapport au temps de cette impulsion est donc de la forme :

Il est donc important de « fenêtrer » la tension pour ne récupérer que la partie positive.
Ce fenêtrage ainsi que la fréquence de commutation du hacheur est assurée par un microcontrôleur.

Dans la suite de notre étude nous ne tiendrons pas compte de la consommation de celui-ci.

===Semaine 16 (25/01/2016)===

* Réflexions sur le prototypage

* Présentation du récupérateur

* Mise en place du banc de test

* Premiers relevés

===Semaine 17 (01/02/2016)===

Test de la quantité d’énergie récupérée par un patch piezo

Méthodologie :

Channel rouge : Tension aux bornes du patch piezo. Ici on observe une fenêtre de tension de 4,5ms imposée par le microcontrôleur.

Channel vert : Tension aux bornes de la capacité C1 de 220nF

[[Fichier:Diffpot.png]]

On constate qu’un choc sur le patch piezo produit une énergie suivent la formule, E = V * N * Δw
N étant une constante électromécanique, on va faire varier V pour évaluer le gain en énergie. Cependant Δw est généré par un choc d’un stylo sur le patch il n’est donc pas uniforme.
Nous utilisons donc une méthode statistique qui consiste à retirer deux extrémum et faire la moyenne de 10 mesures.

Nous obtenons la courbe suivante :

On constate que la courbe n’est pas linéaire comme l’aurai laissé supposer la formule. En effet jusqu’à 30V elle est linéaire croissante suivent l’équation :

Puis après 30V elle devient quadratique décroissante suivent la formule :

En effet la formule E = V * N * Δw néglige les pertes. Celles-ci deviennent plus importante a chaque augmentation de la tension d’alimentation.

On obtient donc un point de fonctionnement optimal a 30V pour notre système. Ce qui impose que notre système soit équipé d’une source de tension en conséquence.

===Semaine 18 (08/02/2016)===
===Semaine 19 (15/02/2016)===
===Semaine 20 (22/02/2016)===

== Annexes ==

Consommation du STM32L4 Series : http://www.st.com/web/en/catalog/mmc/FM141/SC1169/SS1580?sc=stm32l4

Réduction de la consommation de l'Arduino : http://www.home-automation-community.com/arduino-low-power-how-to-run-atmega328p-for-a-year-on-coin-cell-battery/

Consommation Raspberry : https://www.raspberrypi.org/help/faqs/

Module BLE : http://redbearlab.com/blemini/

Accéléromètre : http://fr.farnell.com/analog-devices/adxl345bccz/accelerometre-3-axes-14lga/dp/1853935

Capteur température : http://fr.farnell.com/analog-devices/tmp36gt9z/capteur-temp-to-92-3/dp/1438760?ost=TMP36GT9Z
ou http://fr.farnell.com/stmicroelectronics/stlm20w87f/capteur-de-temperature-analog/dp/1391131

Accéléromètre + Gyroscope : http://fr.farnell.com/invensense/mpu-6050/gyroscope-accelero-6-axes-i2c/dp/1864742

Altimètre : http://fr.farnell.com/freescale-semiconductor/mpl3115a2/pressure-sensor-20-110kpa-8lga/dp/2009084?ost=MPL3115A2&categoryId=700000004367

Explications norme BLE : chapters.comsoc.org/vancouver/BTLER3.pdf

http://www.argenox.com/bluetooth-low-energy-ble-v4-0-development/library/a-ble-advertising-primer/

== Rapport de Mi-projet ==

[[Fichier:CR_Miprojet_Sultana.pdf‎ ]]

Fichier:Montagepiezo.jpg

2016-02-10T15:52:15Z

Qsultana : P32 : Montage piezo

P32 : Montage piezo

P32 Récupération d'énergie pour balise BLE

2016-02-10T15:51:24Z

Qsultana : /* Semaine 13 (04/01/2016) */

== Objectif ==

Mon projet consiste à réaliser un système électronique autonome, composé de différents capteurs et capable de recueillir et de transmettre les données mémorisées vers un système centralisé.

== Etude préalable ==

L’énergie est le point de difficulté dans la réalisation de ce projet. Chaque élément devra être choisi non seulement pour ses performances mais également pour sa faible consommation.

== Organisation générale ==

Le système est organisé autour d’une source d’énergie, d’un contrôleur, de capteurs, de mémoire et d’un protocole de communication.

On cherche à minimiser l'énergie consommée par l'ensemble du système.

[[Fichier:P32Ensemble.PNG|250px|thumb|left|'''Architecture''']]

=== Chaine de l’énergie ===

L’énergie pour ce module autonome est constituée de quatre phases importantes :

[[Fichier:P32Energie.PNG]]

==== La récupération de l'énergie dans l'environnement ====

Il existe de nombreux moyens pour récupérer de l'énergie dans l'environnement. L'objectif est de trouver les sources les plus adaptées à l'environnement de l'application recherchée.

On peut citer:

* La récupération de l'énergie par différence de température

* Les panneaux photovoltaïques

* La récupération de l'énergie des ondes radio

* La Piézoélectricité

Dans ce projet nous utiliserons la piézoélectricité, le module de récupération ayant déjà fait partie d'une étude de IRCICA précédent le projet.

==== Le stockage de l’énergie ====

Le choix du système de stockage de l'énergie constitue une partie importante de la réalisation du système.
La problématique de cette partie sera de déterminer quel type de stockage nous utiliserons : batterie, super-capacité ou un hybride et de les dimensionner.
Il faudra tenir compte des problèmes de décharge partielle influent sur la durée de vie du stockage.

==== Le management/mise en forme de l’énergie ====

L'objectif de cette partie est d'étudier la nécessité de la mise en place d'une régulation tout en préservant des contraintes de consommation très faibles.

==== L'utilisation de l'énergie mise en forme ====

On cherche à minimiser l'énergie consommée par l'ensemble du système.

=== Contrôleur ===

Le microprocesseur : il existe différents types de microprocesseurs. L'objectif est de choisir un support capable de consommer un minimum d'énergie tout en conservant une taille minimale. Nous avons déjà utilisé dans d'autres projets des micro-contrôleurs de type Arduino et Raspberry pie. Ceux-ci ont pour avantage d’être prêts à l'emploi et faciles de prise en main. On peut s’orienter également vers un contrôleur ultra low power comme le STM32L4.

{| class="wikitable centre" width="80%"
|+
|-
! scope=col |
! scope=col | Consommation
! scope=col | Facilité de développement
! scope=col | Miniaturisation
|-
| width="33%" |
<center>Arduino</center>
| width="34%" |
<center>faible à très faible</center>
| width="33%" |
<center>bonne</center>
| width="33%" |
<center>faible</center>
|-
| width="33%" |
<center>Raspberry pi</center>
| width="34%" |
<center>importante</center>
| width="34%" |
<center>très bonne</center>
| width="34%" |
<center>très faible</center>
|-
| width="33%" |
<center>Ultra low power</center>
| width="34%" |
<center>très, très faible</center>
| width="33%" |
<center>difficile</center>
| width="33%" |
<center>forte</center>
|}

=== Capteurs ===

On peut imaginer différents types de capteurs :

* Accéléromètre

* Gyroscope

* Pression atmosphérique et altitude

* Température

* GPS

=== Mémoire ===

Le système doit être autonome et donc conserver un minimum de mesures pour les cas où la connexion est impossible. La mémoire doit être dimensionnée en fonction du nombre de capteurs, l’intervalle d’acquisition et le temps maximum avant connexion au système centralisé.

=== Protocole de communication ===

Un protocole de communication : dans un premier temps, nous nous concentrons sur le protocole BLE (Bluetooth Low Energie). Ce protocole étant standardisé, il nous permettra de recueillir de la documentation et réaliser des tests de consommation rapides.

== Planning prévisionnel ==

[[Fichier:P32Gant.PNG]]

==Suivi de l'avancement du Projet==
===Semaine 1 (28/09/2015)===

* Rencontre avec Monsieur Boe et Monsieur Giraud

* Présentation du projet

* Recherche documentaire

* Etablissement du cahier des charges

===Semaine 2 (05/10/2015)===

Recherche documentaire sur la consommation estimée des différents éléments.

{| class="wikitable centre" width="80%"
|+
|-
! scope=col | '''Contrôleur'''
! scope=col | Consommation Active
! scope=col | Consommation Inactive
! scope=col | Prix
|-
| width="33%" |
<center>Arduino Pro Mini 328 </center>
| width="34%" |
<center> 7mA (1 capteur)</center>
| width="33%" |
<center>4.5µA</center>
| width="33%" |
<center>Disponible</center>
|-
| width="33%" |
<center>STM32L4 Series (STM32L476JE)</center>
| width="34%" |
<center> 100 μA/MHz</center>
| width="33%" |
<center>120 nA</center>
| width="33%" |
<center>$5</center>
|-
| width="33%" |
<center>Raspberry</center>
| width="34%" |
<center> 200mA </center>
| width="33%" |
<center>200mA</center>
| width="33%" |
<center>Disponible</center>
|}

{| class="wikitable centre" width="80%"
|+
|-
! scope=col | '''Module BLE'''
! scope=col | Consommation
! scope=col | Options d'alimentation
! scope=col | Prix
|-
| width="33%" |
<center>BLE Mini</center>
| width="34%" |
<center> 15 mA </center>
| width="33%" |
<center>3.4V à 11V VIN / 5V USB / Coin Cell Battery (2025 or 2032) / 3.7V Li-ion Battery</center>
| width="33%" |
<center>$17</center>
|}

* <s> Le système Mini Arduino/ BLE Mini me semble être un bon compromis entre facilité d’intégration, consommation d'énergie et miniaturisation du système.</s> (Choix à discuter à la réunion du Merdredi 07/10)
* Choix du module RFduino

{| class="wikitable centre" width="80%"
|+
|-
! scope=col | '''Capteurs'''
! scope=col | Modèle
! scope=col | Alimentation min/max
! scope=col | Prix
|-
| width="33%" |
<center>Température</center>
| width="34%" |
<center> TMP36GT9Z </center>
| width="33%" |
<center>2.7V/5.5V</center>
| width="33%" |
<center>1,46 €</center>
|-
| width="33%" |
<center>Accéléromètre</center>
| width="34%" |
<center> ADXL345BCCZ </center>
| width="33%" |
<center>2V/3.6V</center>
| width="33%" |
<center>5,54 €</center>
|-
| width="33%" |
<center>Gyroscope+Accéléromètre</center>
| width="34%" |
<center> MPU-6050</center>
| width="33%" |
<center>2.5V/3.6V</center>
| width="33%" |
<center>15,73 €</center>
|-
| width="33%" |
<center>Pression atmosphérique / Altitude</center>
| width="34%" |
<center> MPL3115A2 </center>
| width="33%" |
<center>1.95V/3.6V</center>
| width="33%" |
<center>2,65 €</center>
|}

* Pour minimiser les pertes on cherche a travailler avec une tension d'alimentation la plus faible possible. Je propose de travailler avec une tension d'alimentation de 3,3V (Validé à discuter à la réunion du Merdredi 07/10)

* Le système de récupération d'énergie fonctionnant sur la base d'un mouvement, j'ai choisi l'ensemble des capteur ci dessus qui me semble être adapté à l'intégration dans un système en mouvement. (Validé à discuter à la réunion du Merdredi 07/10)

* Récupération des modules RFduino, prise en main

===Semaine 3 (12/10/2015)===

* Installation des librairies

* Visualisation d'exemples

* Tests d'implantation du code source du projet P14: Aimant intelligent de la session IMA4: 2014/2015

* Optimisation du code pour la réduction de la consommation d'énergie

* Recherches sur d'autres composants dans l'optique d'une consommation toujours plus faible

{| class="wikitable centre" width="80%"
|+
|-
! scope=col | '''Capteurs'''
! scope=col | Modèle
! scope=col | Alimentation min/max
! scope=col | Prix
! scope=col | Consommation (typ/max)
|-
| width="33%" |
<center>Température</center>
| width="34%" |
<center> STLM20W87F </center>
| width="33%" |
<center>2.4V/5.5V</center>
| width="33%" |
<center> 0,775 € </center>
| width="33%" |
<center> 4.8 μA/8.0 μA </center>
|}

'''Calcul théorique de la consommation énergétique du module BLE + RFD22301'''

Mode "endormi" : ARM CPU Running Current + Output standard drive current = 4 + 0.5 = 4.5mA

Mode "acquisition": ARM CPU Running Current + Output high drive current = 5 + 4 = 9mA

Mode "transmission" : ARM CPU Running Current + Transmit Current + Output standard drive current = 4 + 0.5 + 12 = 16.5mA

http://www.rfduino.com/wp-content/uploads/2014/03/RFD22301.Data_.Sheet_.11.24.13_11.38PM.pdf

'''Code possible du mode "endormi"'''

pinMode(5, INPUT);
RFduino_pinWake(5, HIGH);

RFduino_ULPDelay(INFINITE);
if (RFduino_pinWoke(5))
{
state = ! state;
RFduinoGZLL.sendToHost(state);
}

http://forum.rfduino.com/index.php?topic=385.0

===Semaine 4 (19/10/2015)===

* Réunion du 21/10

* Réalisation de tests

* Ajustement du nombre de capteurs : dans un premier temps on utilisera le capteur de température puis l'accéléromètre

* Discussion sur le bac de test et méthodes de test : résistance de visualisation, chronométrage du temps de transmission, vitesse du processeur

* Réalisation des premiers relevés

===Semaine 5 (26/10/2015)===

* Recherche bibliographique sur les modes d'endormissement du module RFduino

* Essais de codes utilisant un mode d'endormissement plus profond

* Réalisation de graphique de l'énergie utilisée par le module lors de la transmission d'un message par le module BLE.

* Recherches sur des méthodes de programmation pour la diminution de la vitesse processeur

[[Fichier:P32Montage.jpg|250px|thumb|left|'''Montage de test''']]
[[Fichier:P32resultats.jpg|250px|thumb|center|'''Visualisation du courant consommé lors d'envoi toutes les 10ms''']]

* On visualise à l'oscilloscope des pic d'envoi et des pic d'avertissement de la balise BLE, on peut ainsi déduire la puissance nécessaire de chaque action

===Semaine 6 (02/11/2015)===

* Test de diminution de la vitesse processeur

* Réalisation de graphique démontrant l'impact de la réduction de la vitesse processeur sur l'énergie consommée et déduction d'une vitesse optimale pour notre application

* Réunion du 4/11

Définition d'objectifs : Création d'un fichier excel permettant de caractériser les coûts en énergies de chaque étapes de fonctionnement du système.

* Création d'un environnement de test "normé" ( Pour éviter les variations de mesures on réalise un banc et on applique les mêmes conditions de test pour chaque essai)

* Recherche bibliographique sur la norme BLE : recherche du temps maximum entre deux "avertissements" de la balise BLE

===Semaine 7 (09/11/2015)===
* Explication du principe de communication BLE pour l'exploitation des résultats

[[Fichier:Freq.PNG]]

Nous nous intéressons dans notre projet à "l'observateur". Cet objet peut avoir trois états : stand-by, advertising et en communication.

[[Fichier:Brod2.png]]

Dans le mode "Advertising" le système peut :

- Avertir le système récepteur de la proximité d'un capteur

- Avertir de la présence à un appareil souhaitant ce connecter

- Ce reconnecter de façon asynchrone

===Semaine 8 (16/11/2015)===

Analyse en détail d'une trame BLE

[[Fichier:Com.PNG]]

On constate que pendant la durée de la trame il y a un échange entre les deux objets appairé. On s’intéresse ici uniquement aux actions "Slave Tx". Le but étant d'identifier la durée et le courant consommé par ces actions pour obtenir des valeurs en joules.

[[Fichier:SchemaCom.PNG]]

On constate donc deux phases :

- Advertising event

- Connexion event

Nous allons essayer de retrouver et quantifié l'énergie consommé dans ces deux phases.

===Semaine 9 (23/11/2015)===

Lors de cette semaine nous avons effectué des tests en respectant une procédure de test précise. En effet les valeurs des courants que nous relevons sont très petites aussi chaque variation du montage est susceptible de perturber les valeurs.

[[Fichier:P32Conne.jpg|250px|thumb|left|'''Phase connexion''']]

[[Fichier:Avertissement.jpg|250px|thumb|center|'''Phase Advertising''']]

===Semaine 10 (30/11/2015)===

- On cherche a diminuer légèrement la consommation par des modifications logiciel :

Réduction de la puissance de la radio BLE : Diminution de la portée

Augmentation de la fréquence d'advertising : tant que la fréquence d'advetising est inférieure a cette de relevé des capteurs on s'assure que la donnée envoyée est toujours mise à jour.

[[Fichier:Pwl20-envoi.jpg|250px|thumb|left|'''Avec modification logiciel''']]

[[Fichier:Sans-pwlvl.jpg|250px|thumb|center|'''Sans modification logiciel''']]

- On concentre nos résultats dans un tableau récapitulatif en vue du dimensionnement de la batterie du système

[[Fichier:P32tbresul.PNG]]

===Semaine 11 (07/12/2015)===

Tests d'intégration de plusieurs capteur et observations des modification de la consommation des ADC et de la durée/consommation de la transmission.

Réunion de vérification des tests.

Mise en évidence de la dualité consommation d'énergie - Temps de réponse du système

En effet chaque "Advertisement" consomme une quantité d'énergie nous pouvons gérer l'espacement entre ceux-ci mais plus ce temps serra élevé plus il faudra de temps pour ce connecter à ce périphérique.

* Rédaction d'un rapport de test

* Rédaction du rapport de pré soutenance

===Semaine 12 (14/12/2015)===
===Semaine 13 (04/01/2016)===

*Amélioration du modèle

L’amélioration du modèle est réalisée en tenant compte des facteurs influent sur la qualité de la transmission.

* Utilisation d'un picoscope : appareil permettant l’acquisition sur ordinateur de plusieurs formes d'ondes.
Ainsi grâce a un pico scope utilisé à l’IRCICA j’ai pu relever de nombreux échantillons nécessaire a une étude statistique des surcoûts en énergie.

[[Fichier:Montagemulti.jpg|250px|thumb|left|'''Montage multi récepteur''']]

===Semaine 14 (11/01/2016)===

[[Fichier:Emistbrecap.PNG]]

===Semaine 15 (18/01/2016)===

Principe de fonctionnement du récupérateur d’énergie

Le récupérateur d’énergie fonctionne grâce à un patch piezo. Ce patch est capable de produire un courent à partir de la vélocité d’une impulsion suivent la formule :

[[Fichier:Equapiezo.PNG]]

[[Fichier:Modelepizo.PNG|250px|thumb|left|'''Modèle simplifié du patch piezo''']]

Pour récupérer de l’énergie il est couplé au système suivent :

[[Fichier:montagepiezo.PNG]]

La puissance du système est définie par :

P=V*im

L’énergie s’exprime alors :

[[Fichier:Equaenergie.PNG]]

L’énergie produite par le système est donc dépendante de la tension d’alimentation V de la constante électromécanique N et du choc produit sur le patch piezo.
Une impulsion sur le capteur piezo est de la forme :

La dérivée par rapport au temps de cette impulsion est donc de la forme :

Il est donc important de « fenêtrer » la tension pour ne récupérer que la partie positive.
Ce fenêtrage ainsi que la fréquence de commutation du hacheur est assurée par un microcontrôleur.

Dans la suite de notre étude nous ne tiendrons pas compte de la consommation de celui-ci.

===Semaine 16 (25/01/2016)===

* Réflexions sur le prototypage

* Présentation du récupérateur

* Mise en place du banc de test

* Premiers relevés

===Semaine 17 (01/02/2016)===

Test de la quantité d’énergie récupérée par un patch piezo

Méthodologie :

Channel rouge : Tension aux bornes du patch piezo. Ici on observe une fenêtre de tension de 4,5ms imposée par le microcontrôleur.

Channel vert : Tension aux bornes de la capacité C1 de 220nF

[[Fichier:Diffpot.png]]

On constate qu’un choc sur le patch piezo produit une énergie suivent la formule, E = V * N * Δw
N étant une constante électromécanique, on va faire varier V pour évaluer le gain en énergie. Cependant Δw est généré par un choc d’un stylo sur le patch il n’est donc pas uniforme.
Nous utilisons donc une méthode statistique qui consiste à retirer deux extrémum et faire la moyenne de 10 mesures.

Nous obtenons la courbe suivante :

On constate que la courbe n’est pas linéaire comme l’aurai laissé supposer la formule. En effet jusqu’à 30V elle est linéaire croissante suivent l’équation :

Puis après 30V elle devient quadratique décroissante suivent la formule :

En effet la formule E = V * N * Δw néglige les pertes. Celles-ci deviennent plus importante a chaque augmentation de la tension d’alimentation.

On obtient donc un point de fonctionnement optimal a 30V pour notre système. Ce qui impose que notre système soit équipé d’une source de tension en conséquence.

===Semaine 18 (08/02/2016)===
===Semaine 19 (15/02/2016)===
===Semaine 20 (22/02/2016)===

== Annexes ==

Consommation du STM32L4 Series : http://www.st.com/web/en/catalog/mmc/FM141/SC1169/SS1580?sc=stm32l4

Réduction de la consommation de l'Arduino : http://www.home-automation-community.com/arduino-low-power-how-to-run-atmega328p-for-a-year-on-coin-cell-battery/

Consommation Raspberry : https://www.raspberrypi.org/help/faqs/

Module BLE : http://redbearlab.com/blemini/

Accéléromètre : http://fr.farnell.com/analog-devices/adxl345bccz/accelerometre-3-axes-14lga/dp/1853935

Capteur température : http://fr.farnell.com/analog-devices/tmp36gt9z/capteur-temp-to-92-3/dp/1438760?ost=TMP36GT9Z
ou http://fr.farnell.com/stmicroelectronics/stlm20w87f/capteur-de-temperature-analog/dp/1391131

Accéléromètre + Gyroscope : http://fr.farnell.com/invensense/mpu-6050/gyroscope-accelero-6-axes-i2c/dp/1864742

Altimètre : http://fr.farnell.com/freescale-semiconductor/mpl3115a2/pressure-sensor-20-110kpa-8lga/dp/2009084?ost=MPL3115A2&categoryId=700000004367

Explications norme BLE : chapters.comsoc.org/vancouver/BTLER3.pdf

http://www.argenox.com/bluetooth-low-energy-ble-v4-0-development/library/a-ble-advertising-primer/

== Rapport de Mi-projet ==

[[Fichier:CR_Miprojet_Sultana.pdf‎ ]]

Fichier:Montagemulti.jpg

2016-02-10T15:50:22Z

Qsultana : P32 : Montage multi recepteur

P32 : Montage multi recepteur

P32 Récupération d'énergie pour balise BLE

2016-02-10T15:44:01Z

Qsultana : /* Semaine 13 (04/01/2016) */

== Objectif ==

Mon projet consiste à réaliser un système électronique autonome, composé de différents capteurs et capable de recueillir et de transmettre les données mémorisées vers un système centralisé.

== Etude préalable ==

L’énergie est le point de difficulté dans la réalisation de ce projet. Chaque élément devra être choisi non seulement pour ses performances mais également pour sa faible consommation.

== Organisation générale ==

Le système est organisé autour d’une source d’énergie, d’un contrôleur, de capteurs, de mémoire et d’un protocole de communication.

On cherche à minimiser l'énergie consommée par l'ensemble du système.

[[Fichier:P32Ensemble.PNG|250px|thumb|left|'''Architecture''']]

=== Chaine de l’énergie ===

L’énergie pour ce module autonome est constituée de quatre phases importantes :

[[Fichier:P32Energie.PNG]]

==== La récupération de l'énergie dans l'environnement ====

Il existe de nombreux moyens pour récupérer de l'énergie dans l'environnement. L'objectif est de trouver les sources les plus adaptées à l'environnement de l'application recherchée.

On peut citer:

* La récupération de l'énergie par différence de température

* Les panneaux photovoltaïques

* La récupération de l'énergie des ondes radio

* La Piézoélectricité

Dans ce projet nous utiliserons la piézoélectricité, le module de récupération ayant déjà fait partie d'une étude de IRCICA précédent le projet.

==== Le stockage de l’énergie ====

Le choix du système de stockage de l'énergie constitue une partie importante de la réalisation du système.
La problématique de cette partie sera de déterminer quel type de stockage nous utiliserons : batterie, super-capacité ou un hybride et de les dimensionner.
Il faudra tenir compte des problèmes de décharge partielle influent sur la durée de vie du stockage.

==== Le management/mise en forme de l’énergie ====

L'objectif de cette partie est d'étudier la nécessité de la mise en place d'une régulation tout en préservant des contraintes de consommation très faibles.

==== L'utilisation de l'énergie mise en forme ====

On cherche à minimiser l'énergie consommée par l'ensemble du système.

=== Contrôleur ===

Le microprocesseur : il existe différents types de microprocesseurs. L'objectif est de choisir un support capable de consommer un minimum d'énergie tout en conservant une taille minimale. Nous avons déjà utilisé dans d'autres projets des micro-contrôleurs de type Arduino et Raspberry pie. Ceux-ci ont pour avantage d’être prêts à l'emploi et faciles de prise en main. On peut s’orienter également vers un contrôleur ultra low power comme le STM32L4.

{| class="wikitable centre" width="80%"
|+
|-
! scope=col |
! scope=col | Consommation
! scope=col | Facilité de développement
! scope=col | Miniaturisation
|-
| width="33%" |
<center>Arduino</center>
| width="34%" |
<center>faible à très faible</center>
| width="33%" |
<center>bonne</center>
| width="33%" |
<center>faible</center>
|-
| width="33%" |
<center>Raspberry pi</center>
| width="34%" |
<center>importante</center>
| width="34%" |
<center>très bonne</center>
| width="34%" |
<center>très faible</center>
|-
| width="33%" |
<center>Ultra low power</center>
| width="34%" |
<center>très, très faible</center>
| width="33%" |
<center>difficile</center>
| width="33%" |
<center>forte</center>
|}

=== Capteurs ===

On peut imaginer différents types de capteurs :

* Accéléromètre

* Gyroscope

* Pression atmosphérique et altitude

* Température

* GPS

=== Mémoire ===

Le système doit être autonome et donc conserver un minimum de mesures pour les cas où la connexion est impossible. La mémoire doit être dimensionnée en fonction du nombre de capteurs, l’intervalle d’acquisition et le temps maximum avant connexion au système centralisé.

=== Protocole de communication ===

Un protocole de communication : dans un premier temps, nous nous concentrons sur le protocole BLE (Bluetooth Low Energie). Ce protocole étant standardisé, il nous permettra de recueillir de la documentation et réaliser des tests de consommation rapides.

== Planning prévisionnel ==

[[Fichier:P32Gant.PNG]]

==Suivi de l'avancement du Projet==
===Semaine 1 (28/09/2015)===

* Rencontre avec Monsieur Boe et Monsieur Giraud

* Présentation du projet

* Recherche documentaire

* Etablissement du cahier des charges

===Semaine 2 (05/10/2015)===

Recherche documentaire sur la consommation estimée des différents éléments.

{| class="wikitable centre" width="80%"
|+
|-
! scope=col | '''Contrôleur'''
! scope=col | Consommation Active
! scope=col | Consommation Inactive
! scope=col | Prix
|-
| width="33%" |
<center>Arduino Pro Mini 328 </center>
| width="34%" |
<center> 7mA (1 capteur)</center>
| width="33%" |
<center>4.5µA</center>
| width="33%" |
<center>Disponible</center>
|-
| width="33%" |
<center>STM32L4 Series (STM32L476JE)</center>
| width="34%" |
<center> 100 μA/MHz</center>
| width="33%" |
<center>120 nA</center>
| width="33%" |
<center>$5</center>
|-
| width="33%" |
<center>Raspberry</center>
| width="34%" |
<center> 200mA </center>
| width="33%" |
<center>200mA</center>
| width="33%" |
<center>Disponible</center>
|}

{| class="wikitable centre" width="80%"
|+
|-
! scope=col | '''Module BLE'''
! scope=col | Consommation
! scope=col | Options d'alimentation
! scope=col | Prix
|-
| width="33%" |
<center>BLE Mini</center>
| width="34%" |
<center> 15 mA </center>
| width="33%" |
<center>3.4V à 11V VIN / 5V USB / Coin Cell Battery (2025 or 2032) / 3.7V Li-ion Battery</center>
| width="33%" |
<center>$17</center>
|}

* <s> Le système Mini Arduino/ BLE Mini me semble être un bon compromis entre facilité d’intégration, consommation d'énergie et miniaturisation du système.</s> (Choix à discuter à la réunion du Merdredi 07/10)
* Choix du module RFduino

{| class="wikitable centre" width="80%"
|+
|-
! scope=col | '''Capteurs'''
! scope=col | Modèle
! scope=col | Alimentation min/max
! scope=col | Prix
|-
| width="33%" |
<center>Température</center>
| width="34%" |
<center> TMP36GT9Z </center>
| width="33%" |
<center>2.7V/5.5V</center>
| width="33%" |
<center>1,46 €</center>
|-
| width="33%" |
<center>Accéléromètre</center>
| width="34%" |
<center> ADXL345BCCZ </center>
| width="33%" |
<center>2V/3.6V</center>
| width="33%" |
<center>5,54 €</center>
|-
| width="33%" |
<center>Gyroscope+Accéléromètre</center>
| width="34%" |
<center> MPU-6050</center>
| width="33%" |
<center>2.5V/3.6V</center>
| width="33%" |
<center>15,73 €</center>
|-
| width="33%" |
<center>Pression atmosphérique / Altitude</center>
| width="34%" |
<center> MPL3115A2 </center>
| width="33%" |
<center>1.95V/3.6V</center>
| width="33%" |
<center>2,65 €</center>
|}

* Pour minimiser les pertes on cherche a travailler avec une tension d'alimentation la plus faible possible. Je propose de travailler avec une tension d'alimentation de 3,3V (Validé à discuter à la réunion du Merdredi 07/10)

* Le système de récupération d'énergie fonctionnant sur la base d'un mouvement, j'ai choisi l'ensemble des capteur ci dessus qui me semble être adapté à l'intégration dans un système en mouvement. (Validé à discuter à la réunion du Merdredi 07/10)

* Récupération des modules RFduino, prise en main

===Semaine 3 (12/10/2015)===

* Installation des librairies

* Visualisation d'exemples

* Tests d'implantation du code source du projet P14: Aimant intelligent de la session IMA4: 2014/2015

* Optimisation du code pour la réduction de la consommation d'énergie

* Recherches sur d'autres composants dans l'optique d'une consommation toujours plus faible

{| class="wikitable centre" width="80%"
|+
|-
! scope=col | '''Capteurs'''
! scope=col | Modèle
! scope=col | Alimentation min/max
! scope=col | Prix
! scope=col | Consommation (typ/max)
|-
| width="33%" |
<center>Température</center>
| width="34%" |
<center> STLM20W87F </center>
| width="33%" |
<center>2.4V/5.5V</center>
| width="33%" |
<center> 0,775 € </center>
| width="33%" |
<center> 4.8 μA/8.0 μA </center>
|}

'''Calcul théorique de la consommation énergétique du module BLE + RFD22301'''

Mode "endormi" : ARM CPU Running Current + Output standard drive current = 4 + 0.5 = 4.5mA

Mode "acquisition": ARM CPU Running Current + Output high drive current = 5 + 4 = 9mA

Mode "transmission" : ARM CPU Running Current + Transmit Current + Output standard drive current = 4 + 0.5 + 12 = 16.5mA

http://www.rfduino.com/wp-content/uploads/2014/03/RFD22301.Data_.Sheet_.11.24.13_11.38PM.pdf

'''Code possible du mode "endormi"'''

pinMode(5, INPUT);
RFduino_pinWake(5, HIGH);

RFduino_ULPDelay(INFINITE);
if (RFduino_pinWoke(5))
{
state = ! state;
RFduinoGZLL.sendToHost(state);
}

http://forum.rfduino.com/index.php?topic=385.0

===Semaine 4 (19/10/2015)===

* Réunion du 21/10

* Réalisation de tests

* Ajustement du nombre de capteurs : dans un premier temps on utilisera le capteur de température puis l'accéléromètre

* Discussion sur le bac de test et méthodes de test : résistance de visualisation, chronométrage du temps de transmission, vitesse du processeur

* Réalisation des premiers relevés

===Semaine 5 (26/10/2015)===

* Recherche bibliographique sur les modes d'endormissement du module RFduino

* Essais de codes utilisant un mode d'endormissement plus profond

* Réalisation de graphique de l'énergie utilisée par le module lors de la transmission d'un message par le module BLE.

* Recherches sur des méthodes de programmation pour la diminution de la vitesse processeur

[[Fichier:P32Montage.jpg|250px|thumb|left|'''Montage de test''']]
[[Fichier:P32resultats.jpg|250px|thumb|center|'''Visualisation du courant consommé lors d'envoi toutes les 10ms''']]

* On visualise à l'oscilloscope des pic d'envoi et des pic d'avertissement de la balise BLE, on peut ainsi déduire la puissance nécessaire de chaque action

===Semaine 6 (02/11/2015)===

* Test de diminution de la vitesse processeur

* Réalisation de graphique démontrant l'impact de la réduction de la vitesse processeur sur l'énergie consommée et déduction d'une vitesse optimale pour notre application

* Réunion du 4/11

Définition d'objectifs : Création d'un fichier excel permettant de caractériser les coûts en énergies de chaque étapes de fonctionnement du système.

* Création d'un environnement de test "normé" ( Pour éviter les variations de mesures on réalise un banc et on applique les mêmes conditions de test pour chaque essai)

* Recherche bibliographique sur la norme BLE : recherche du temps maximum entre deux "avertissements" de la balise BLE

===Semaine 7 (09/11/2015)===
* Explication du principe de communication BLE pour l'exploitation des résultats

[[Fichier:Freq.PNG]]

Nous nous intéressons dans notre projet à "l'observateur". Cet objet peut avoir trois états : stand-by, advertising et en communication.

[[Fichier:Brod2.png]]

Dans le mode "Advertising" le système peut :

- Avertir le système récepteur de la proximité d'un capteur

- Avertir de la présence à un appareil souhaitant ce connecter

- Ce reconnecter de façon asynchrone

===Semaine 8 (16/11/2015)===

Analyse en détail d'une trame BLE

[[Fichier:Com.PNG]]

On constate que pendant la durée de la trame il y a un échange entre les deux objets appairé. On s’intéresse ici uniquement aux actions "Slave Tx". Le but étant d'identifier la durée et le courant consommé par ces actions pour obtenir des valeurs en joules.

[[Fichier:SchemaCom.PNG]]

On constate donc deux phases :

- Advertising event

- Connexion event

Nous allons essayer de retrouver et quantifié l'énergie consommé dans ces deux phases.

===Semaine 9 (23/11/2015)===

Lors de cette semaine nous avons effectué des tests en respectant une procédure de test précise. En effet les valeurs des courants que nous relevons sont très petites aussi chaque variation du montage est susceptible de perturber les valeurs.

[[Fichier:P32Conne.jpg|250px|thumb|left|'''Phase connexion''']]

[[Fichier:Avertissement.jpg|250px|thumb|center|'''Phase Advertising''']]

===Semaine 10 (30/11/2015)===

- On cherche a diminuer légèrement la consommation par des modifications logiciel :

Réduction de la puissance de la radio BLE : Diminution de la portée

Augmentation de la fréquence d'advertising : tant que la fréquence d'advetising est inférieure a cette de relevé des capteurs on s'assure que la donnée envoyée est toujours mise à jour.

[[Fichier:Pwl20-envoi.jpg|250px|thumb|left|'''Avec modification logiciel''']]

[[Fichier:Sans-pwlvl.jpg|250px|thumb|center|'''Sans modification logiciel''']]

- On concentre nos résultats dans un tableau récapitulatif en vue du dimensionnement de la batterie du système

[[Fichier:P32tbresul.PNG]]

===Semaine 11 (07/12/2015)===

Tests d'intégration de plusieurs capteur et observations des modification de la consommation des ADC et de la durée/consommation de la transmission.

Réunion de vérification des tests.

Mise en évidence de la dualité consommation d'énergie - Temps de réponse du système

En effet chaque "Advertisement" consomme une quantité d'énergie nous pouvons gérer l'espacement entre ceux-ci mais plus ce temps serra élevé plus il faudra de temps pour ce connecter à ce périphérique.

* Rédaction d'un rapport de test

* Rédaction du rapport de pré soutenance

===Semaine 12 (14/12/2015)===
===Semaine 13 (04/01/2016)===

*Amélioration du modèle

L’amélioration du modèle est réalisée en tenant compte des facteurs influent sur la qualité de la transmission.

* Utilisation d'un picoscope : appareil permettant l’acquisition sur ordinateur de plusieurs formes d'ondes.
Ainsi grâce a un pico scope utilisé à l’IRCICA j’ai pu relever de nombreux échantillons nécessaire a une étude statistique des surcoûts en énergie.

===Semaine 14 (11/01/2016)===

[[Fichier:Emistbrecap.PNG]]

===Semaine 15 (18/01/2016)===

Principe de fonctionnement du récupérateur d’énergie

Le récupérateur d’énergie fonctionne grâce à un patch piezo. Ce patch est capable de produire un courent à partir de la vélocité d’une impulsion suivent la formule :

[[Fichier:Equapiezo.PNG]]

[[Fichier:Modelepizo.PNG|250px|thumb|left|'''Modèle simplifié du patch piezo''']]

Pour récupérer de l’énergie il est couplé au système suivent :

[[Fichier:montagepiezo.PNG]]

La puissance du système est définie par :

P=V*im

L’énergie s’exprime alors :

[[Fichier:Equaenergie.PNG]]

L’énergie produite par le système est donc dépendante de la tension d’alimentation V de la constante électromécanique N et du choc produit sur le patch piezo.
Une impulsion sur le capteur piezo est de la forme :

La dérivée par rapport au temps de cette impulsion est donc de la forme :

Il est donc important de « fenêtrer » la tension pour ne récupérer que la partie positive.
Ce fenêtrage ainsi que la fréquence de commutation du hacheur est assurée par un microcontrôleur.

Dans la suite de notre étude nous ne tiendrons pas compte de la consommation de celui-ci.

===Semaine 16 (25/01/2016)===

* Réflexions sur le prototypage

* Présentation du récupérateur

* Mise en place du banc de test

* Premiers relevés

===Semaine 17 (01/02/2016)===

Test de la quantité d’énergie récupérée par un patch piezo

Méthodologie :

Channel rouge : Tension aux bornes du patch piezo. Ici on observe une fenêtre de tension de 4,5ms imposée par le microcontrôleur.

Channel vert : Tension aux bornes de la capacité C1 de 220nF

[[Fichier:Diffpot.png]]

On constate qu’un choc sur le patch piezo produit une énergie suivent la formule, E = V * N * Δw
N étant une constante électromécanique, on va faire varier V pour évaluer le gain en énergie. Cependant Δw est généré par un choc d’un stylo sur le patch il n’est donc pas uniforme.
Nous utilisons donc une méthode statistique qui consiste à retirer deux extrémum et faire la moyenne de 10 mesures.

Nous obtenons la courbe suivante :

On constate que la courbe n’est pas linéaire comme l’aurai laissé supposer la formule. En effet jusqu’à 30V elle est linéaire croissante suivent l’équation :

Puis après 30V elle devient quadratique décroissante suivent la formule :

En effet la formule E = V * N * Δw néglige les pertes. Celles-ci deviennent plus importante a chaque augmentation de la tension d’alimentation.

On obtient donc un point de fonctionnement optimal a 30V pour notre système. Ce qui impose que notre système soit équipé d’une source de tension en conséquence.

===Semaine 18 (08/02/2016)===
===Semaine 19 (15/02/2016)===
===Semaine 20 (22/02/2016)===

== Annexes ==

Consommation du STM32L4 Series : http://www.st.com/web/en/catalog/mmc/FM141/SC1169/SS1580?sc=stm32l4

Réduction de la consommation de l'Arduino : http://www.home-automation-community.com/arduino-low-power-how-to-run-atmega328p-for-a-year-on-coin-cell-battery/

Consommation Raspberry : https://www.raspberrypi.org/help/faqs/

Module BLE : http://redbearlab.com/blemini/

Accéléromètre : http://fr.farnell.com/analog-devices/adxl345bccz/accelerometre-3-axes-14lga/dp/1853935

Capteur température : http://fr.farnell.com/analog-devices/tmp36gt9z/capteur-temp-to-92-3/dp/1438760?ost=TMP36GT9Z
ou http://fr.farnell.com/stmicroelectronics/stlm20w87f/capteur-de-temperature-analog/dp/1391131

Accéléromètre + Gyroscope : http://fr.farnell.com/invensense/mpu-6050/gyroscope-accelero-6-axes-i2c/dp/1864742

Altimètre : http://fr.farnell.com/freescale-semiconductor/mpl3115a2/pressure-sensor-20-110kpa-8lga/dp/2009084?ost=MPL3115A2&categoryId=700000004367

Explications norme BLE : chapters.comsoc.org/vancouver/BTLER3.pdf

http://www.argenox.com/bluetooth-low-energy-ble-v4-0-development/library/a-ble-advertising-primer/

== Rapport de Mi-projet ==

[[Fichier:CR_Miprojet_Sultana.pdf‎ ]]

P32 Récupération d'énergie pour balise BLE

2016-02-10T15:42:40Z

Qsultana : /* Semaine 16 (25/01/2016) */

== Objectif ==

Mon projet consiste à réaliser un système électronique autonome, composé de différents capteurs et capable de recueillir et de transmettre les données mémorisées vers un système centralisé.

== Etude préalable ==

L’énergie est le point de difficulté dans la réalisation de ce projet. Chaque élément devra être choisi non seulement pour ses performances mais également pour sa faible consommation.

== Organisation générale ==

Le système est organisé autour d’une source d’énergie, d’un contrôleur, de capteurs, de mémoire et d’un protocole de communication.

On cherche à minimiser l'énergie consommée par l'ensemble du système.

[[Fichier:P32Ensemble.PNG|250px|thumb|left|'''Architecture''']]

=== Chaine de l’énergie ===

L’énergie pour ce module autonome est constituée de quatre phases importantes :

[[Fichier:P32Energie.PNG]]

==== La récupération de l'énergie dans l'environnement ====

Il existe de nombreux moyens pour récupérer de l'énergie dans l'environnement. L'objectif est de trouver les sources les plus adaptées à l'environnement de l'application recherchée.

On peut citer:

* La récupération de l'énergie par différence de température

* Les panneaux photovoltaïques

* La récupération de l'énergie des ondes radio

* La Piézoélectricité

Dans ce projet nous utiliserons la piézoélectricité, le module de récupération ayant déjà fait partie d'une étude de IRCICA précédent le projet.

==== Le stockage de l’énergie ====

Le choix du système de stockage de l'énergie constitue une partie importante de la réalisation du système.
La problématique de cette partie sera de déterminer quel type de stockage nous utiliserons : batterie, super-capacité ou un hybride et de les dimensionner.
Il faudra tenir compte des problèmes de décharge partielle influent sur la durée de vie du stockage.

==== Le management/mise en forme de l’énergie ====

L'objectif de cette partie est d'étudier la nécessité de la mise en place d'une régulation tout en préservant des contraintes de consommation très faibles.

==== L'utilisation de l'énergie mise en forme ====

On cherche à minimiser l'énergie consommée par l'ensemble du système.

=== Contrôleur ===

Le microprocesseur : il existe différents types de microprocesseurs. L'objectif est de choisir un support capable de consommer un minimum d'énergie tout en conservant une taille minimale. Nous avons déjà utilisé dans d'autres projets des micro-contrôleurs de type Arduino et Raspberry pie. Ceux-ci ont pour avantage d’être prêts à l'emploi et faciles de prise en main. On peut s’orienter également vers un contrôleur ultra low power comme le STM32L4.

{| class="wikitable centre" width="80%"
|+
|-
! scope=col |
! scope=col | Consommation
! scope=col | Facilité de développement
! scope=col | Miniaturisation
|-
| width="33%" |
<center>Arduino</center>
| width="34%" |
<center>faible à très faible</center>
| width="33%" |
<center>bonne</center>
| width="33%" |
<center>faible</center>
|-
| width="33%" |
<center>Raspberry pi</center>
| width="34%" |
<center>importante</center>
| width="34%" |
<center>très bonne</center>
| width="34%" |
<center>très faible</center>
|-
| width="33%" |
<center>Ultra low power</center>
| width="34%" |
<center>très, très faible</center>
| width="33%" |
<center>difficile</center>
| width="33%" |
<center>forte</center>
|}

=== Capteurs ===

On peut imaginer différents types de capteurs :

* Accéléromètre

* Gyroscope

* Pression atmosphérique et altitude

* Température

* GPS

=== Mémoire ===

Le système doit être autonome et donc conserver un minimum de mesures pour les cas où la connexion est impossible. La mémoire doit être dimensionnée en fonction du nombre de capteurs, l’intervalle d’acquisition et le temps maximum avant connexion au système centralisé.

=== Protocole de communication ===

Un protocole de communication : dans un premier temps, nous nous concentrons sur le protocole BLE (Bluetooth Low Energie). Ce protocole étant standardisé, il nous permettra de recueillir de la documentation et réaliser des tests de consommation rapides.

== Planning prévisionnel ==

[[Fichier:P32Gant.PNG]]

==Suivi de l'avancement du Projet==
===Semaine 1 (28/09/2015)===

* Rencontre avec Monsieur Boe et Monsieur Giraud

* Présentation du projet

* Recherche documentaire

* Etablissement du cahier des charges

===Semaine 2 (05/10/2015)===

Recherche documentaire sur la consommation estimée des différents éléments.

{| class="wikitable centre" width="80%"
|+
|-
! scope=col | '''Contrôleur'''
! scope=col | Consommation Active
! scope=col | Consommation Inactive
! scope=col | Prix
|-
| width="33%" |
<center>Arduino Pro Mini 328 </center>
| width="34%" |
<center> 7mA (1 capteur)</center>
| width="33%" |
<center>4.5µA</center>
| width="33%" |
<center>Disponible</center>
|-
| width="33%" |
<center>STM32L4 Series (STM32L476JE)</center>
| width="34%" |
<center> 100 μA/MHz</center>
| width="33%" |
<center>120 nA</center>
| width="33%" |
<center>$5</center>
|-
| width="33%" |
<center>Raspberry</center>
| width="34%" |
<center> 200mA </center>
| width="33%" |
<center>200mA</center>
| width="33%" |
<center>Disponible</center>
|}

{| class="wikitable centre" width="80%"
|+
|-
! scope=col | '''Module BLE'''
! scope=col | Consommation
! scope=col | Options d'alimentation
! scope=col | Prix
|-
| width="33%" |
<center>BLE Mini</center>
| width="34%" |
<center> 15 mA </center>
| width="33%" |
<center>3.4V à 11V VIN / 5V USB / Coin Cell Battery (2025 or 2032) / 3.7V Li-ion Battery</center>
| width="33%" |
<center>$17</center>
|}

* <s> Le système Mini Arduino/ BLE Mini me semble être un bon compromis entre facilité d’intégration, consommation d'énergie et miniaturisation du système.</s> (Choix à discuter à la réunion du Merdredi 07/10)
* Choix du module RFduino

{| class="wikitable centre" width="80%"
|+
|-
! scope=col | '''Capteurs'''
! scope=col | Modèle
! scope=col | Alimentation min/max
! scope=col | Prix
|-
| width="33%" |
<center>Température</center>
| width="34%" |
<center> TMP36GT9Z </center>
| width="33%" |
<center>2.7V/5.5V</center>
| width="33%" |
<center>1,46 €</center>
|-
| width="33%" |
<center>Accéléromètre</center>
| width="34%" |
<center> ADXL345BCCZ </center>
| width="33%" |
<center>2V/3.6V</center>
| width="33%" |
<center>5,54 €</center>
|-
| width="33%" |
<center>Gyroscope+Accéléromètre</center>
| width="34%" |
<center> MPU-6050</center>
| width="33%" |
<center>2.5V/3.6V</center>
| width="33%" |
<center>15,73 €</center>
|-
| width="33%" |
<center>Pression atmosphérique / Altitude</center>
| width="34%" |
<center> MPL3115A2 </center>
| width="33%" |
<center>1.95V/3.6V</center>
| width="33%" |
<center>2,65 €</center>
|}

* Pour minimiser les pertes on cherche a travailler avec une tension d'alimentation la plus faible possible. Je propose de travailler avec une tension d'alimentation de 3,3V (Validé à discuter à la réunion du Merdredi 07/10)

* Le système de récupération d'énergie fonctionnant sur la base d'un mouvement, j'ai choisi l'ensemble des capteur ci dessus qui me semble être adapté à l'intégration dans un système en mouvement. (Validé à discuter à la réunion du Merdredi 07/10)

* Récupération des modules RFduino, prise en main

===Semaine 3 (12/10/2015)===

* Installation des librairies

* Visualisation d'exemples

* Tests d'implantation du code source du projet P14: Aimant intelligent de la session IMA4: 2014/2015

* Optimisation du code pour la réduction de la consommation d'énergie

* Recherches sur d'autres composants dans l'optique d'une consommation toujours plus faible

{| class="wikitable centre" width="80%"
|+
|-
! scope=col | '''Capteurs'''
! scope=col | Modèle
! scope=col | Alimentation min/max
! scope=col | Prix
! scope=col | Consommation (typ/max)
|-
| width="33%" |
<center>Température</center>
| width="34%" |
<center> STLM20W87F </center>
| width="33%" |
<center>2.4V/5.5V</center>
| width="33%" |
<center> 0,775 € </center>
| width="33%" |
<center> 4.8 μA/8.0 μA </center>
|}

'''Calcul théorique de la consommation énergétique du module BLE + RFD22301'''

Mode "endormi" : ARM CPU Running Current + Output standard drive current = 4 + 0.5 = 4.5mA

Mode "acquisition": ARM CPU Running Current + Output high drive current = 5 + 4 = 9mA

Mode "transmission" : ARM CPU Running Current + Transmit Current + Output standard drive current = 4 + 0.5 + 12 = 16.5mA

http://www.rfduino.com/wp-content/uploads/2014/03/RFD22301.Data_.Sheet_.11.24.13_11.38PM.pdf

'''Code possible du mode "endormi"'''

pinMode(5, INPUT);
RFduino_pinWake(5, HIGH);

RFduino_ULPDelay(INFINITE);
if (RFduino_pinWoke(5))
{
state = ! state;
RFduinoGZLL.sendToHost(state);
}

http://forum.rfduino.com/index.php?topic=385.0

===Semaine 4 (19/10/2015)===

* Réunion du 21/10

* Réalisation de tests

* Ajustement du nombre de capteurs : dans un premier temps on utilisera le capteur de température puis l'accéléromètre

* Discussion sur le bac de test et méthodes de test : résistance de visualisation, chronométrage du temps de transmission, vitesse du processeur

* Réalisation des premiers relevés

===Semaine 5 (26/10/2015)===

* Recherche bibliographique sur les modes d'endormissement du module RFduino

* Essais de codes utilisant un mode d'endormissement plus profond

* Réalisation de graphique de l'énergie utilisée par le module lors de la transmission d'un message par le module BLE.

* Recherches sur des méthodes de programmation pour la diminution de la vitesse processeur

[[Fichier:P32Montage.jpg|250px|thumb|left|'''Montage de test''']]
[[Fichier:P32resultats.jpg|250px|thumb|center|'''Visualisation du courant consommé lors d'envoi toutes les 10ms''']]

* On visualise à l'oscilloscope des pic d'envoi et des pic d'avertissement de la balise BLE, on peut ainsi déduire la puissance nécessaire de chaque action

===Semaine 6 (02/11/2015)===

* Test de diminution de la vitesse processeur

* Réalisation de graphique démontrant l'impact de la réduction de la vitesse processeur sur l'énergie consommée et déduction d'une vitesse optimale pour notre application

* Réunion du 4/11

Définition d'objectifs : Création d'un fichier excel permettant de caractériser les coûts en énergies de chaque étapes de fonctionnement du système.

* Création d'un environnement de test "normé" ( Pour éviter les variations de mesures on réalise un banc et on applique les mêmes conditions de test pour chaque essai)

* Recherche bibliographique sur la norme BLE : recherche du temps maximum entre deux "avertissements" de la balise BLE

===Semaine 7 (09/11/2015)===
* Explication du principe de communication BLE pour l'exploitation des résultats

[[Fichier:Freq.PNG]]

Nous nous intéressons dans notre projet à "l'observateur". Cet objet peut avoir trois états : stand-by, advertising et en communication.

[[Fichier:Brod2.png]]

Dans le mode "Advertising" le système peut :

- Avertir le système récepteur de la proximité d'un capteur

- Avertir de la présence à un appareil souhaitant ce connecter

- Ce reconnecter de façon asynchrone

===Semaine 8 (16/11/2015)===

Analyse en détail d'une trame BLE

[[Fichier:Com.PNG]]

On constate que pendant la durée de la trame il y a un échange entre les deux objets appairé. On s’intéresse ici uniquement aux actions "Slave Tx". Le but étant d'identifier la durée et le courant consommé par ces actions pour obtenir des valeurs en joules.

[[Fichier:SchemaCom.PNG]]

On constate donc deux phases :

- Advertising event

- Connexion event

Nous allons essayer de retrouver et quantifié l'énergie consommé dans ces deux phases.

===Semaine 9 (23/11/2015)===

Lors de cette semaine nous avons effectué des tests en respectant une procédure de test précise. En effet les valeurs des courants que nous relevons sont très petites aussi chaque variation du montage est susceptible de perturber les valeurs.

[[Fichier:P32Conne.jpg|250px|thumb|left|'''Phase connexion''']]

[[Fichier:Avertissement.jpg|250px|thumb|center|'''Phase Advertising''']]

===Semaine 10 (30/11/2015)===

- On cherche a diminuer légèrement la consommation par des modifications logiciel :

Réduction de la puissance de la radio BLE : Diminution de la portée

Augmentation de la fréquence d'advertising : tant que la fréquence d'advetising est inférieure a cette de relevé des capteurs on s'assure que la donnée envoyée est toujours mise à jour.

[[Fichier:Pwl20-envoi.jpg|250px|thumb|left|'''Avec modification logiciel''']]

[[Fichier:Sans-pwlvl.jpg|250px|thumb|center|'''Sans modification logiciel''']]

- On concentre nos résultats dans un tableau récapitulatif en vue du dimensionnement de la batterie du système

[[Fichier:P32tbresul.PNG]]

===Semaine 11 (07/12/2015)===

Tests d'intégration de plusieurs capteur et observations des modification de la consommation des ADC et de la durée/consommation de la transmission.

Réunion de vérification des tests.

Mise en évidence de la dualité consommation d'énergie - Temps de réponse du système

En effet chaque "Advertisement" consomme une quantité d'énergie nous pouvons gérer l'espacement entre ceux-ci mais plus ce temps serra élevé plus il faudra de temps pour ce connecter à ce périphérique.

* Rédaction d'un rapport de test

* Rédaction du rapport de pré soutenance

===Semaine 12 (14/12/2015)===
===Semaine 13 (04/01/2016)===

*Amélioration du modèle

L’amélioration du modèle est réalisée en tenant compte des facteurs influent sur la qualité de la transmission.
Ainsi grâce a un pico scope utilisé à l’IRCICA j’ai pu relever de nombreux échantillons nécessaire a une étude statistique des surcoûts en énergie.

===Semaine 14 (11/01/2016)===

[[Fichier:Emistbrecap.PNG]]

===Semaine 15 (18/01/2016)===

Principe de fonctionnement du récupérateur d’énergie

Le récupérateur d’énergie fonctionne grâce à un patch piezo. Ce patch est capable de produire un courent à partir de la vélocité d’une impulsion suivent la formule :

[[Fichier:Equapiezo.PNG]]

[[Fichier:Modelepizo.PNG|250px|thumb|left|'''Modèle simplifié du patch piezo''']]

Pour récupérer de l’énergie il est couplé au système suivent :

[[Fichier:montagepiezo.PNG]]

La puissance du système est définie par :

P=V*im

L’énergie s’exprime alors :

[[Fichier:Equaenergie.PNG]]

L’énergie produite par le système est donc dépendante de la tension d’alimentation V de la constante électromécanique N et du choc produit sur le patch piezo.
Une impulsion sur le capteur piezo est de la forme :

La dérivée par rapport au temps de cette impulsion est donc de la forme :

Il est donc important de « fenêtrer » la tension pour ne récupérer que la partie positive.
Ce fenêtrage ainsi que la fréquence de commutation du hacheur est assurée par un microcontrôleur.

Dans la suite de notre étude nous ne tiendrons pas compte de la consommation de celui-ci.

===Semaine 16 (25/01/2016)===

* Réflexions sur le prototypage

* Présentation du récupérateur

* Mise en place du banc de test

* Premiers relevés

===Semaine 17 (01/02/2016)===

Test de la quantité d’énergie récupérée par un patch piezo

Méthodologie :

Channel rouge : Tension aux bornes du patch piezo. Ici on observe une fenêtre de tension de 4,5ms imposée par le microcontrôleur.

Channel vert : Tension aux bornes de la capacité C1 de 220nF

[[Fichier:Diffpot.png]]

On constate qu’un choc sur le patch piezo produit une énergie suivent la formule, E = V * N * Δw
N étant une constante électromécanique, on va faire varier V pour évaluer le gain en énergie. Cependant Δw est généré par un choc d’un stylo sur le patch il n’est donc pas uniforme.
Nous utilisons donc une méthode statistique qui consiste à retirer deux extrémum et faire la moyenne de 10 mesures.

Nous obtenons la courbe suivante :

On constate que la courbe n’est pas linéaire comme l’aurai laissé supposer la formule. En effet jusqu’à 30V elle est linéaire croissante suivent l’équation :

Puis après 30V elle devient quadratique décroissante suivent la formule :

En effet la formule E = V * N * Δw néglige les pertes. Celles-ci deviennent plus importante a chaque augmentation de la tension d’alimentation.

On obtient donc un point de fonctionnement optimal a 30V pour notre système. Ce qui impose que notre système soit équipé d’une source de tension en conséquence.

===Semaine 18 (08/02/2016)===
===Semaine 19 (15/02/2016)===
===Semaine 20 (22/02/2016)===

== Annexes ==

Consommation du STM32L4 Series : http://www.st.com/web/en/catalog/mmc/FM141/SC1169/SS1580?sc=stm32l4

Réduction de la consommation de l'Arduino : http://www.home-automation-community.com/arduino-low-power-how-to-run-atmega328p-for-a-year-on-coin-cell-battery/

Consommation Raspberry : https://www.raspberrypi.org/help/faqs/

Module BLE : http://redbearlab.com/blemini/

Accéléromètre : http://fr.farnell.com/analog-devices/adxl345bccz/accelerometre-3-axes-14lga/dp/1853935

Capteur température : http://fr.farnell.com/analog-devices/tmp36gt9z/capteur-temp-to-92-3/dp/1438760?ost=TMP36GT9Z
ou http://fr.farnell.com/stmicroelectronics/stlm20w87f/capteur-de-temperature-analog/dp/1391131

Accéléromètre + Gyroscope : http://fr.farnell.com/invensense/mpu-6050/gyroscope-accelero-6-axes-i2c/dp/1864742

Altimètre : http://fr.farnell.com/freescale-semiconductor/mpl3115a2/pressure-sensor-20-110kpa-8lga/dp/2009084?ost=MPL3115A2&categoryId=700000004367

Explications norme BLE : chapters.comsoc.org/vancouver/BTLER3.pdf

http://www.argenox.com/bluetooth-low-energy-ble-v4-0-development/library/a-ble-advertising-primer/

== Rapport de Mi-projet ==

[[Fichier:CR_Miprojet_Sultana.pdf‎ ]]

P32 Récupération d'énergie pour balise BLE

2016-02-10T15:40:54Z

Qsultana : /* Semaine 14 (11/01/2016) */

== Objectif ==

Mon projet consiste à réaliser un système électronique autonome, composé de différents capteurs et capable de recueillir et de transmettre les données mémorisées vers un système centralisé.

== Etude préalable ==

L’énergie est le point de difficulté dans la réalisation de ce projet. Chaque élément devra être choisi non seulement pour ses performances mais également pour sa faible consommation.

== Organisation générale ==

Le système est organisé autour d’une source d’énergie, d’un contrôleur, de capteurs, de mémoire et d’un protocole de communication.

On cherche à minimiser l'énergie consommée par l'ensemble du système.

[[Fichier:P32Ensemble.PNG|250px|thumb|left|'''Architecture''']]

=== Chaine de l’énergie ===

L’énergie pour ce module autonome est constituée de quatre phases importantes :

[[Fichier:P32Energie.PNG]]

==== La récupération de l'énergie dans l'environnement ====

Il existe de nombreux moyens pour récupérer de l'énergie dans l'environnement. L'objectif est de trouver les sources les plus adaptées à l'environnement de l'application recherchée.

On peut citer:

* La récupération de l'énergie par différence de température

* Les panneaux photovoltaïques

* La récupération de l'énergie des ondes radio

* La Piézoélectricité

Dans ce projet nous utiliserons la piézoélectricité, le module de récupération ayant déjà fait partie d'une étude de IRCICA précédent le projet.

==== Le stockage de l’énergie ====

Le choix du système de stockage de l'énergie constitue une partie importante de la réalisation du système.
La problématique de cette partie sera de déterminer quel type de stockage nous utiliserons : batterie, super-capacité ou un hybride et de les dimensionner.
Il faudra tenir compte des problèmes de décharge partielle influent sur la durée de vie du stockage.

==== Le management/mise en forme de l’énergie ====

L'objectif de cette partie est d'étudier la nécessité de la mise en place d'une régulation tout en préservant des contraintes de consommation très faibles.

==== L'utilisation de l'énergie mise en forme ====

On cherche à minimiser l'énergie consommée par l'ensemble du système.

=== Contrôleur ===

Le microprocesseur : il existe différents types de microprocesseurs. L'objectif est de choisir un support capable de consommer un minimum d'énergie tout en conservant une taille minimale. Nous avons déjà utilisé dans d'autres projets des micro-contrôleurs de type Arduino et Raspberry pie. Ceux-ci ont pour avantage d’être prêts à l'emploi et faciles de prise en main. On peut s’orienter également vers un contrôleur ultra low power comme le STM32L4.

{| class="wikitable centre" width="80%"
|+
|-
! scope=col |
! scope=col | Consommation
! scope=col | Facilité de développement
! scope=col | Miniaturisation
|-
| width="33%" |
<center>Arduino</center>
| width="34%" |
<center>faible à très faible</center>
| width="33%" |
<center>bonne</center>
| width="33%" |
<center>faible</center>
|-
| width="33%" |
<center>Raspberry pi</center>
| width="34%" |
<center>importante</center>
| width="34%" |
<center>très bonne</center>
| width="34%" |
<center>très faible</center>
|-
| width="33%" |
<center>Ultra low power</center>
| width="34%" |
<center>très, très faible</center>
| width="33%" |
<center>difficile</center>
| width="33%" |
<center>forte</center>
|}

=== Capteurs ===

On peut imaginer différents types de capteurs :

* Accéléromètre

* Gyroscope

* Pression atmosphérique et altitude

* Température

* GPS

=== Mémoire ===

Le système doit être autonome et donc conserver un minimum de mesures pour les cas où la connexion est impossible. La mémoire doit être dimensionnée en fonction du nombre de capteurs, l’intervalle d’acquisition et le temps maximum avant connexion au système centralisé.

=== Protocole de communication ===

Un protocole de communication : dans un premier temps, nous nous concentrons sur le protocole BLE (Bluetooth Low Energie). Ce protocole étant standardisé, il nous permettra de recueillir de la documentation et réaliser des tests de consommation rapides.

== Planning prévisionnel ==

[[Fichier:P32Gant.PNG]]

==Suivi de l'avancement du Projet==
===Semaine 1 (28/09/2015)===

* Rencontre avec Monsieur Boe et Monsieur Giraud

* Présentation du projet

* Recherche documentaire

* Etablissement du cahier des charges

===Semaine 2 (05/10/2015)===

Recherche documentaire sur la consommation estimée des différents éléments.

{| class="wikitable centre" width="80%"
|+
|-
! scope=col | '''Contrôleur'''
! scope=col | Consommation Active
! scope=col | Consommation Inactive
! scope=col | Prix
|-
| width="33%" |
<center>Arduino Pro Mini 328 </center>
| width="34%" |
<center> 7mA (1 capteur)</center>
| width="33%" |
<center>4.5µA</center>
| width="33%" |
<center>Disponible</center>
|-
| width="33%" |
<center>STM32L4 Series (STM32L476JE)</center>
| width="34%" |
<center> 100 μA/MHz</center>
| width="33%" |
<center>120 nA</center>
| width="33%" |
<center>$5</center>
|-
| width="33%" |
<center>Raspberry</center>
| width="34%" |
<center> 200mA </center>
| width="33%" |
<center>200mA</center>
| width="33%" |
<center>Disponible</center>
|}

{| class="wikitable centre" width="80%"
|+
|-
! scope=col | '''Module BLE'''
! scope=col | Consommation
! scope=col | Options d'alimentation
! scope=col | Prix
|-
| width="33%" |
<center>BLE Mini</center>
| width="34%" |
<center> 15 mA </center>
| width="33%" |
<center>3.4V à 11V VIN / 5V USB / Coin Cell Battery (2025 or 2032) / 3.7V Li-ion Battery</center>
| width="33%" |
<center>$17</center>
|}

* <s> Le système Mini Arduino/ BLE Mini me semble être un bon compromis entre facilité d’intégration, consommation d'énergie et miniaturisation du système.</s> (Choix à discuter à la réunion du Merdredi 07/10)
* Choix du module RFduino

{| class="wikitable centre" width="80%"
|+
|-
! scope=col | '''Capteurs'''
! scope=col | Modèle
! scope=col | Alimentation min/max
! scope=col | Prix
|-
| width="33%" |
<center>Température</center>
| width="34%" |
<center> TMP36GT9Z </center>
| width="33%" |
<center>2.7V/5.5V</center>
| width="33%" |
<center>1,46 €</center>
|-
| width="33%" |
<center>Accéléromètre</center>
| width="34%" |
<center> ADXL345BCCZ </center>
| width="33%" |
<center>2V/3.6V</center>
| width="33%" |
<center>5,54 €</center>
|-
| width="33%" |
<center>Gyroscope+Accéléromètre</center>
| width="34%" |
<center> MPU-6050</center>
| width="33%" |
<center>2.5V/3.6V</center>
| width="33%" |
<center>15,73 €</center>
|-
| width="33%" |
<center>Pression atmosphérique / Altitude</center>
| width="34%" |
<center> MPL3115A2 </center>
| width="33%" |
<center>1.95V/3.6V</center>
| width="33%" |
<center>2,65 €</center>
|}

* Pour minimiser les pertes on cherche a travailler avec une tension d'alimentation la plus faible possible. Je propose de travailler avec une tension d'alimentation de 3,3V (Validé à discuter à la réunion du Merdredi 07/10)

* Le système de récupération d'énergie fonctionnant sur la base d'un mouvement, j'ai choisi l'ensemble des capteur ci dessus qui me semble être adapté à l'intégration dans un système en mouvement. (Validé à discuter à la réunion du Merdredi 07/10)

* Récupération des modules RFduino, prise en main

===Semaine 3 (12/10/2015)===

* Installation des librairies

* Visualisation d'exemples

* Tests d'implantation du code source du projet P14: Aimant intelligent de la session IMA4: 2014/2015

* Optimisation du code pour la réduction de la consommation d'énergie

* Recherches sur d'autres composants dans l'optique d'une consommation toujours plus faible

{| class="wikitable centre" width="80%"
|+
|-
! scope=col | '''Capteurs'''
! scope=col | Modèle
! scope=col | Alimentation min/max
! scope=col | Prix
! scope=col | Consommation (typ/max)
|-
| width="33%" |
<center>Température</center>
| width="34%" |
<center> STLM20W87F </center>
| width="33%" |
<center>2.4V/5.5V</center>
| width="33%" |
<center> 0,775 € </center>
| width="33%" |
<center> 4.8 μA/8.0 μA </center>
|}

'''Calcul théorique de la consommation énergétique du module BLE + RFD22301'''

Mode "endormi" : ARM CPU Running Current + Output standard drive current = 4 + 0.5 = 4.5mA

Mode "acquisition": ARM CPU Running Current + Output high drive current = 5 + 4 = 9mA

Mode "transmission" : ARM CPU Running Current + Transmit Current + Output standard drive current = 4 + 0.5 + 12 = 16.5mA

http://www.rfduino.com/wp-content/uploads/2014/03/RFD22301.Data_.Sheet_.11.24.13_11.38PM.pdf

'''Code possible du mode "endormi"'''

pinMode(5, INPUT);
RFduino_pinWake(5, HIGH);

RFduino_ULPDelay(INFINITE);
if (RFduino_pinWoke(5))
{
state = ! state;
RFduinoGZLL.sendToHost(state);
}

http://forum.rfduino.com/index.php?topic=385.0

===Semaine 4 (19/10/2015)===

* Réunion du 21/10

* Réalisation de tests

* Ajustement du nombre de capteurs : dans un premier temps on utilisera le capteur de température puis l'accéléromètre

* Discussion sur le bac de test et méthodes de test : résistance de visualisation, chronométrage du temps de transmission, vitesse du processeur

* Réalisation des premiers relevés

===Semaine 5 (26/10/2015)===

* Recherche bibliographique sur les modes d'endormissement du module RFduino

* Essais de codes utilisant un mode d'endormissement plus profond

* Réalisation de graphique de l'énergie utilisée par le module lors de la transmission d'un message par le module BLE.

* Recherches sur des méthodes de programmation pour la diminution de la vitesse processeur

[[Fichier:P32Montage.jpg|250px|thumb|left|'''Montage de test''']]
[[Fichier:P32resultats.jpg|250px|thumb|center|'''Visualisation du courant consommé lors d'envoi toutes les 10ms''']]

* On visualise à l'oscilloscope des pic d'envoi et des pic d'avertissement de la balise BLE, on peut ainsi déduire la puissance nécessaire de chaque action

===Semaine 6 (02/11/2015)===

* Test de diminution de la vitesse processeur

* Réalisation de graphique démontrant l'impact de la réduction de la vitesse processeur sur l'énergie consommée et déduction d'une vitesse optimale pour notre application

* Réunion du 4/11

Définition d'objectifs : Création d'un fichier excel permettant de caractériser les coûts en énergies de chaque étapes de fonctionnement du système.

* Création d'un environnement de test "normé" ( Pour éviter les variations de mesures on réalise un banc et on applique les mêmes conditions de test pour chaque essai)

* Recherche bibliographique sur la norme BLE : recherche du temps maximum entre deux "avertissements" de la balise BLE

===Semaine 7 (09/11/2015)===
* Explication du principe de communication BLE pour l'exploitation des résultats

[[Fichier:Freq.PNG]]

Nous nous intéressons dans notre projet à "l'observateur". Cet objet peut avoir trois états : stand-by, advertising et en communication.

[[Fichier:Brod2.png]]

Dans le mode "Advertising" le système peut :

- Avertir le système récepteur de la proximité d'un capteur

- Avertir de la présence à un appareil souhaitant ce connecter

- Ce reconnecter de façon asynchrone

===Semaine 8 (16/11/2015)===

Analyse en détail d'une trame BLE

[[Fichier:Com.PNG]]

On constate que pendant la durée de la trame il y a un échange entre les deux objets appairé. On s’intéresse ici uniquement aux actions "Slave Tx". Le but étant d'identifier la durée et le courant consommé par ces actions pour obtenir des valeurs en joules.

[[Fichier:SchemaCom.PNG]]

On constate donc deux phases :

- Advertising event

- Connexion event

Nous allons essayer de retrouver et quantifié l'énergie consommé dans ces deux phases.

===Semaine 9 (23/11/2015)===

Lors de cette semaine nous avons effectué des tests en respectant une procédure de test précise. En effet les valeurs des courants que nous relevons sont très petites aussi chaque variation du montage est susceptible de perturber les valeurs.

[[Fichier:P32Conne.jpg|250px|thumb|left|'''Phase connexion''']]

[[Fichier:Avertissement.jpg|250px|thumb|center|'''Phase Advertising''']]

===Semaine 10 (30/11/2015)===

- On cherche a diminuer légèrement la consommation par des modifications logiciel :

Réduction de la puissance de la radio BLE : Diminution de la portée

Augmentation de la fréquence d'advertising : tant que la fréquence d'advetising est inférieure a cette de relevé des capteurs on s'assure que la donnée envoyée est toujours mise à jour.

[[Fichier:Pwl20-envoi.jpg|250px|thumb|left|'''Avec modification logiciel''']]

[[Fichier:Sans-pwlvl.jpg|250px|thumb|center|'''Sans modification logiciel''']]

- On concentre nos résultats dans un tableau récapitulatif en vue du dimensionnement de la batterie du système

[[Fichier:P32tbresul.PNG]]

===Semaine 11 (07/12/2015)===

Tests d'intégration de plusieurs capteur et observations des modification de la consommation des ADC et de la durée/consommation de la transmission.

Réunion de vérification des tests.

Mise en évidence de la dualité consommation d'énergie - Temps de réponse du système

En effet chaque "Advertisement" consomme une quantité d'énergie nous pouvons gérer l'espacement entre ceux-ci mais plus ce temps serra élevé plus il faudra de temps pour ce connecter à ce périphérique.

* Rédaction d'un rapport de test

* Rédaction du rapport de pré soutenance

===Semaine 12 (14/12/2015)===
===Semaine 13 (04/01/2016)===

*Amélioration du modèle

L’amélioration du modèle est réalisée en tenant compte des facteurs influent sur la qualité de la transmission.
Ainsi grâce a un pico scope utilisé à l’IRCICA j’ai pu relever de nombreux échantillons nécessaire a une étude statistique des surcoûts en énergie.

===Semaine 14 (11/01/2016)===

[[Fichier:Emistbrecap.PNG]]

===Semaine 15 (18/01/2016)===

Principe de fonctionnement du récupérateur d’énergie

Le récupérateur d’énergie fonctionne grâce à un patch piezo. Ce patch est capable de produire un courent à partir de la vélocité d’une impulsion suivent la formule :

[[Fichier:Equapiezo.PNG]]

[[Fichier:Modelepizo.PNG|250px|thumb|left|'''Modèle simplifié du patch piezo''']]

Pour récupérer de l’énergie il est couplé au système suivent :

[[Fichier:montagepiezo.PNG]]

La puissance du système est définie par :

P=V*im

L’énergie s’exprime alors :

[[Fichier:Equaenergie.PNG]]

L’énergie produite par le système est donc dépendante de la tension d’alimentation V de la constante électromécanique N et du choc produit sur le patch piezo.
Une impulsion sur le capteur piezo est de la forme :

La dérivée par rapport au temps de cette impulsion est donc de la forme :

Il est donc important de « fenêtrer » la tension pour ne récupérer que la partie positive.
Ce fenêtrage ainsi que la fréquence de commutation du hacheur est assurée par un microcontrôleur.

Dans la suite de notre étude nous ne tiendrons pas compte de la consommation de celui-ci.

===Semaine 16 (25/01/2016)===
===Semaine 17 (01/02/2016)===

Test de la quantité d’énergie récupérée par un patch piezo

Méthodologie :

Channel rouge : Tension aux bornes du patch piezo. Ici on observe une fenêtre de tension de 4,5ms imposée par le microcontrôleur.

Channel vert : Tension aux bornes de la capacité C1 de 220nF

[[Fichier:Diffpot.png]]

On constate qu’un choc sur le patch piezo produit une énergie suivent la formule, E = V * N * Δw
N étant une constante électromécanique, on va faire varier V pour évaluer le gain en énergie. Cependant Δw est généré par un choc d’un stylo sur le patch il n’est donc pas uniforme.
Nous utilisons donc une méthode statistique qui consiste à retirer deux extrémum et faire la moyenne de 10 mesures.

Nous obtenons la courbe suivante :

On constate que la courbe n’est pas linéaire comme l’aurai laissé supposer la formule. En effet jusqu’à 30V elle est linéaire croissante suivent l’équation :

Puis après 30V elle devient quadratique décroissante suivent la formule :

En effet la formule E = V * N * Δw néglige les pertes. Celles-ci deviennent plus importante a chaque augmentation de la tension d’alimentation.

On obtient donc un point de fonctionnement optimal a 30V pour notre système. Ce qui impose que notre système soit équipé d’une source de tension en conséquence.

===Semaine 18 (08/02/2016)===
===Semaine 19 (15/02/2016)===
===Semaine 20 (22/02/2016)===

== Annexes ==

Consommation du STM32L4 Series : http://www.st.com/web/en/catalog/mmc/FM141/SC1169/SS1580?sc=stm32l4

Réduction de la consommation de l'Arduino : http://www.home-automation-community.com/arduino-low-power-how-to-run-atmega328p-for-a-year-on-coin-cell-battery/

Consommation Raspberry : https://www.raspberrypi.org/help/faqs/

Module BLE : http://redbearlab.com/blemini/

Accéléromètre : http://fr.farnell.com/analog-devices/adxl345bccz/accelerometre-3-axes-14lga/dp/1853935

Capteur température : http://fr.farnell.com/analog-devices/tmp36gt9z/capteur-temp-to-92-3/dp/1438760?ost=TMP36GT9Z
ou http://fr.farnell.com/stmicroelectronics/stlm20w87f/capteur-de-temperature-analog/dp/1391131

Accéléromètre + Gyroscope : http://fr.farnell.com/invensense/mpu-6050/gyroscope-accelero-6-axes-i2c/dp/1864742

Altimètre : http://fr.farnell.com/freescale-semiconductor/mpl3115a2/pressure-sensor-20-110kpa-8lga/dp/2009084?ost=MPL3115A2&categoryId=700000004367

Explications norme BLE : chapters.comsoc.org/vancouver/BTLER3.pdf

http://www.argenox.com/bluetooth-low-energy-ble-v4-0-development/library/a-ble-advertising-primer/

== Rapport de Mi-projet ==

[[Fichier:CR_Miprojet_Sultana.pdf‎ ]]

Fichier:Emistbrecap.PNG

2016-02-10T15:40:28Z

Qsultana : P32 : résultats de l'étude statistique sur les événements aléatoires sur l'emission

P32 : résultats de l'étude statistique sur les événements aléatoires sur l'emission

P32 Récupération d'énergie pour balise BLE

2016-02-10T15:38:21Z

Qsultana : /* Semaine 17 (01/02/2016) */

== Objectif ==

Mon projet consiste à réaliser un système électronique autonome, composé de différents capteurs et capable de recueillir et de transmettre les données mémorisées vers un système centralisé.

== Etude préalable ==

L’énergie est le point de difficulté dans la réalisation de ce projet. Chaque élément devra être choisi non seulement pour ses performances mais également pour sa faible consommation.

== Organisation générale ==

Le système est organisé autour d’une source d’énergie, d’un contrôleur, de capteurs, de mémoire et d’un protocole de communication.

On cherche à minimiser l'énergie consommée par l'ensemble du système.

[[Fichier:P32Ensemble.PNG|250px|thumb|left|'''Architecture''']]

=== Chaine de l’énergie ===

L’énergie pour ce module autonome est constituée de quatre phases importantes :

[[Fichier:P32Energie.PNG]]

==== La récupération de l'énergie dans l'environnement ====

Il existe de nombreux moyens pour récupérer de l'énergie dans l'environnement. L'objectif est de trouver les sources les plus adaptées à l'environnement de l'application recherchée.

On peut citer:

* La récupération de l'énergie par différence de température

* Les panneaux photovoltaïques

* La récupération de l'énergie des ondes radio

* La Piézoélectricité

Dans ce projet nous utiliserons la piézoélectricité, le module de récupération ayant déjà fait partie d'une étude de IRCICA précédent le projet.

==== Le stockage de l’énergie ====

Le choix du système de stockage de l'énergie constitue une partie importante de la réalisation du système.
La problématique de cette partie sera de déterminer quel type de stockage nous utiliserons : batterie, super-capacité ou un hybride et de les dimensionner.
Il faudra tenir compte des problèmes de décharge partielle influent sur la durée de vie du stockage.

==== Le management/mise en forme de l’énergie ====

L'objectif de cette partie est d'étudier la nécessité de la mise en place d'une régulation tout en préservant des contraintes de consommation très faibles.

==== L'utilisation de l'énergie mise en forme ====

On cherche à minimiser l'énergie consommée par l'ensemble du système.

=== Contrôleur ===

Le microprocesseur : il existe différents types de microprocesseurs. L'objectif est de choisir un support capable de consommer un minimum d'énergie tout en conservant une taille minimale. Nous avons déjà utilisé dans d'autres projets des micro-contrôleurs de type Arduino et Raspberry pie. Ceux-ci ont pour avantage d’être prêts à l'emploi et faciles de prise en main. On peut s’orienter également vers un contrôleur ultra low power comme le STM32L4.

{| class="wikitable centre" width="80%"
|+
|-
! scope=col |
! scope=col | Consommation
! scope=col | Facilité de développement
! scope=col | Miniaturisation
|-
| width="33%" |
<center>Arduino</center>
| width="34%" |
<center>faible à très faible</center>
| width="33%" |
<center>bonne</center>
| width="33%" |
<center>faible</center>
|-
| width="33%" |
<center>Raspberry pi</center>
| width="34%" |
<center>importante</center>
| width="34%" |
<center>très bonne</center>
| width="34%" |
<center>très faible</center>
|-
| width="33%" |
<center>Ultra low power</center>
| width="34%" |
<center>très, très faible</center>
| width="33%" |
<center>difficile</center>
| width="33%" |
<center>forte</center>
|}

=== Capteurs ===

On peut imaginer différents types de capteurs :

* Accéléromètre

* Gyroscope

* Pression atmosphérique et altitude

* Température

* GPS

=== Mémoire ===

Le système doit être autonome et donc conserver un minimum de mesures pour les cas où la connexion est impossible. La mémoire doit être dimensionnée en fonction du nombre de capteurs, l’intervalle d’acquisition et le temps maximum avant connexion au système centralisé.

=== Protocole de communication ===

Un protocole de communication : dans un premier temps, nous nous concentrons sur le protocole BLE (Bluetooth Low Energie). Ce protocole étant standardisé, il nous permettra de recueillir de la documentation et réaliser des tests de consommation rapides.

== Planning prévisionnel ==

[[Fichier:P32Gant.PNG]]

==Suivi de l'avancement du Projet==
===Semaine 1 (28/09/2015)===

* Rencontre avec Monsieur Boe et Monsieur Giraud

* Présentation du projet

* Recherche documentaire

* Etablissement du cahier des charges

===Semaine 2 (05/10/2015)===

Recherche documentaire sur la consommation estimée des différents éléments.

{| class="wikitable centre" width="80%"
|+
|-
! scope=col | '''Contrôleur'''
! scope=col | Consommation Active
! scope=col | Consommation Inactive
! scope=col | Prix
|-
| width="33%" |
<center>Arduino Pro Mini 328 </center>
| width="34%" |
<center> 7mA (1 capteur)</center>
| width="33%" |
<center>4.5µA</center>
| width="33%" |
<center>Disponible</center>
|-
| width="33%" |
<center>STM32L4 Series (STM32L476JE)</center>
| width="34%" |
<center> 100 μA/MHz</center>
| width="33%" |
<center>120 nA</center>
| width="33%" |
<center>$5</center>
|-
| width="33%" |
<center>Raspberry</center>
| width="34%" |
<center> 200mA </center>
| width="33%" |
<center>200mA</center>
| width="33%" |
<center>Disponible</center>
|}

{| class="wikitable centre" width="80%"
|+
|-
! scope=col | '''Module BLE'''
! scope=col | Consommation
! scope=col | Options d'alimentation
! scope=col | Prix
|-
| width="33%" |
<center>BLE Mini</center>
| width="34%" |
<center> 15 mA </center>
| width="33%" |
<center>3.4V à 11V VIN / 5V USB / Coin Cell Battery (2025 or 2032) / 3.7V Li-ion Battery</center>
| width="33%" |
<center>$17</center>
|}

* <s> Le système Mini Arduino/ BLE Mini me semble être un bon compromis entre facilité d’intégration, consommation d'énergie et miniaturisation du système.</s> (Choix à discuter à la réunion du Merdredi 07/10)
* Choix du module RFduino

{| class="wikitable centre" width="80%"
|+
|-
! scope=col | '''Capteurs'''
! scope=col | Modèle
! scope=col | Alimentation min/max
! scope=col | Prix
|-
| width="33%" |
<center>Température</center>
| width="34%" |
<center> TMP36GT9Z </center>
| width="33%" |
<center>2.7V/5.5V</center>
| width="33%" |
<center>1,46 €</center>
|-
| width="33%" |
<center>Accéléromètre</center>
| width="34%" |
<center> ADXL345BCCZ </center>
| width="33%" |
<center>2V/3.6V</center>
| width="33%" |
<center>5,54 €</center>
|-
| width="33%" |
<center>Gyroscope+Accéléromètre</center>
| width="34%" |
<center> MPU-6050</center>
| width="33%" |
<center>2.5V/3.6V</center>
| width="33%" |
<center>15,73 €</center>
|-
| width="33%" |
<center>Pression atmosphérique / Altitude</center>
| width="34%" |
<center> MPL3115A2 </center>
| width="33%" |
<center>1.95V/3.6V</center>
| width="33%" |
<center>2,65 €</center>
|}

* Pour minimiser les pertes on cherche a travailler avec une tension d'alimentation la plus faible possible. Je propose de travailler avec une tension d'alimentation de 3,3V (Validé à discuter à la réunion du Merdredi 07/10)

* Le système de récupération d'énergie fonctionnant sur la base d'un mouvement, j'ai choisi l'ensemble des capteur ci dessus qui me semble être adapté à l'intégration dans un système en mouvement. (Validé à discuter à la réunion du Merdredi 07/10)

* Récupération des modules RFduino, prise en main

===Semaine 3 (12/10/2015)===

* Installation des librairies

* Visualisation d'exemples

* Tests d'implantation du code source du projet P14: Aimant intelligent de la session IMA4: 2014/2015

* Optimisation du code pour la réduction de la consommation d'énergie

* Recherches sur d'autres composants dans l'optique d'une consommation toujours plus faible

{| class="wikitable centre" width="80%"
|+
|-
! scope=col | '''Capteurs'''
! scope=col | Modèle
! scope=col | Alimentation min/max
! scope=col | Prix
! scope=col | Consommation (typ/max)
|-
| width="33%" |
<center>Température</center>
| width="34%" |
<center> STLM20W87F </center>
| width="33%" |
<center>2.4V/5.5V</center>
| width="33%" |
<center> 0,775 € </center>
| width="33%" |
<center> 4.8 μA/8.0 μA </center>
|}

'''Calcul théorique de la consommation énergétique du module BLE + RFD22301'''

Mode "endormi" : ARM CPU Running Current + Output standard drive current = 4 + 0.5 = 4.5mA

Mode "acquisition": ARM CPU Running Current + Output high drive current = 5 + 4 = 9mA

Mode "transmission" : ARM CPU Running Current + Transmit Current + Output standard drive current = 4 + 0.5 + 12 = 16.5mA

http://www.rfduino.com/wp-content/uploads/2014/03/RFD22301.Data_.Sheet_.11.24.13_11.38PM.pdf

'''Code possible du mode "endormi"'''

pinMode(5, INPUT);
RFduino_pinWake(5, HIGH);

RFduino_ULPDelay(INFINITE);
if (RFduino_pinWoke(5))
{
state = ! state;
RFduinoGZLL.sendToHost(state);
}

http://forum.rfduino.com/index.php?topic=385.0

===Semaine 4 (19/10/2015)===

* Réunion du 21/10

* Réalisation de tests

* Ajustement du nombre de capteurs : dans un premier temps on utilisera le capteur de température puis l'accéléromètre

* Discussion sur le bac de test et méthodes de test : résistance de visualisation, chronométrage du temps de transmission, vitesse du processeur

* Réalisation des premiers relevés

===Semaine 5 (26/10/2015)===

* Recherche bibliographique sur les modes d'endormissement du module RFduino

* Essais de codes utilisant un mode d'endormissement plus profond

* Réalisation de graphique de l'énergie utilisée par le module lors de la transmission d'un message par le module BLE.

* Recherches sur des méthodes de programmation pour la diminution de la vitesse processeur

[[Fichier:P32Montage.jpg|250px|thumb|left|'''Montage de test''']]
[[Fichier:P32resultats.jpg|250px|thumb|center|'''Visualisation du courant consommé lors d'envoi toutes les 10ms''']]

* On visualise à l'oscilloscope des pic d'envoi et des pic d'avertissement de la balise BLE, on peut ainsi déduire la puissance nécessaire de chaque action

===Semaine 6 (02/11/2015)===

* Test de diminution de la vitesse processeur

* Réalisation de graphique démontrant l'impact de la réduction de la vitesse processeur sur l'énergie consommée et déduction d'une vitesse optimale pour notre application

* Réunion du 4/11

Définition d'objectifs : Création d'un fichier excel permettant de caractériser les coûts en énergies de chaque étapes de fonctionnement du système.

* Création d'un environnement de test "normé" ( Pour éviter les variations de mesures on réalise un banc et on applique les mêmes conditions de test pour chaque essai)

* Recherche bibliographique sur la norme BLE : recherche du temps maximum entre deux "avertissements" de la balise BLE

===Semaine 7 (09/11/2015)===
* Explication du principe de communication BLE pour l'exploitation des résultats

[[Fichier:Freq.PNG]]

Nous nous intéressons dans notre projet à "l'observateur". Cet objet peut avoir trois états : stand-by, advertising et en communication.

[[Fichier:Brod2.png]]

Dans le mode "Advertising" le système peut :

- Avertir le système récepteur de la proximité d'un capteur

- Avertir de la présence à un appareil souhaitant ce connecter

- Ce reconnecter de façon asynchrone

===Semaine 8 (16/11/2015)===

Analyse en détail d'une trame BLE

[[Fichier:Com.PNG]]

On constate que pendant la durée de la trame il y a un échange entre les deux objets appairé. On s’intéresse ici uniquement aux actions "Slave Tx". Le but étant d'identifier la durée et le courant consommé par ces actions pour obtenir des valeurs en joules.

[[Fichier:SchemaCom.PNG]]

On constate donc deux phases :

- Advertising event

- Connexion event

Nous allons essayer de retrouver et quantifié l'énergie consommé dans ces deux phases.

===Semaine 9 (23/11/2015)===

Lors de cette semaine nous avons effectué des tests en respectant une procédure de test précise. En effet les valeurs des courants que nous relevons sont très petites aussi chaque variation du montage est susceptible de perturber les valeurs.

[[Fichier:P32Conne.jpg|250px|thumb|left|'''Phase connexion''']]

[[Fichier:Avertissement.jpg|250px|thumb|center|'''Phase Advertising''']]

===Semaine 10 (30/11/2015)===

- On cherche a diminuer légèrement la consommation par des modifications logiciel :

Réduction de la puissance de la radio BLE : Diminution de la portée

Augmentation de la fréquence d'advertising : tant que la fréquence d'advetising est inférieure a cette de relevé des capteurs on s'assure que la donnée envoyée est toujours mise à jour.

[[Fichier:Pwl20-envoi.jpg|250px|thumb|left|'''Avec modification logiciel''']]

[[Fichier:Sans-pwlvl.jpg|250px|thumb|center|'''Sans modification logiciel''']]

- On concentre nos résultats dans un tableau récapitulatif en vue du dimensionnement de la batterie du système

[[Fichier:P32tbresul.PNG]]

===Semaine 11 (07/12/2015)===

Tests d'intégration de plusieurs capteur et observations des modification de la consommation des ADC et de la durée/consommation de la transmission.

Réunion de vérification des tests.

Mise en évidence de la dualité consommation d'énergie - Temps de réponse du système

En effet chaque "Advertisement" consomme une quantité d'énergie nous pouvons gérer l'espacement entre ceux-ci mais plus ce temps serra élevé plus il faudra de temps pour ce connecter à ce périphérique.

* Rédaction d'un rapport de test

* Rédaction du rapport de pré soutenance

===Semaine 12 (14/12/2015)===
===Semaine 13 (04/01/2016)===

*Amélioration du modèle

L’amélioration du modèle est réalisée en tenant compte des facteurs influent sur la qualité de la transmission.
Ainsi grâce a un pico scope utilisé à l’IRCICA j’ai pu relever de nombreux échantillons nécessaire a une étude statistique des surcoûts en énergie.

===Semaine 14 (11/01/2016)===
===Semaine 15 (18/01/2016)===

Principe de fonctionnement du récupérateur d’énergie

Le récupérateur d’énergie fonctionne grâce à un patch piezo. Ce patch est capable de produire un courent à partir de la vélocité d’une impulsion suivent la formule :

[[Fichier:Equapiezo.PNG]]

[[Fichier:Modelepizo.PNG|250px|thumb|left|'''Modèle simplifié du patch piezo''']]

Pour récupérer de l’énergie il est couplé au système suivent :

[[Fichier:montagepiezo.PNG]]

La puissance du système est définie par :

P=V*im

L’énergie s’exprime alors :

[[Fichier:Equaenergie.PNG]]

L’énergie produite par le système est donc dépendante de la tension d’alimentation V de la constante électromécanique N et du choc produit sur le patch piezo.
Une impulsion sur le capteur piezo est de la forme :

La dérivée par rapport au temps de cette impulsion est donc de la forme :

Il est donc important de « fenêtrer » la tension pour ne récupérer que la partie positive.
Ce fenêtrage ainsi que la fréquence de commutation du hacheur est assurée par un microcontrôleur.

Dans la suite de notre étude nous ne tiendrons pas compte de la consommation de celui-ci.

===Semaine 16 (25/01/2016)===
===Semaine 17 (01/02/2016)===

Test de la quantité d’énergie récupérée par un patch piezo

Méthodologie :

Channel rouge : Tension aux bornes du patch piezo. Ici on observe une fenêtre de tension de 4,5ms imposée par le microcontrôleur.

Channel vert : Tension aux bornes de la capacité C1 de 220nF

[[Fichier:Diffpot.png]]

On constate qu’un choc sur le patch piezo produit une énergie suivent la formule, E = V * N * Δw
N étant une constante électromécanique, on va faire varier V pour évaluer le gain en énergie. Cependant Δw est généré par un choc d’un stylo sur le patch il n’est donc pas uniforme.
Nous utilisons donc une méthode statistique qui consiste à retirer deux extrémum et faire la moyenne de 10 mesures.

Nous obtenons la courbe suivante :

On constate que la courbe n’est pas linéaire comme l’aurai laissé supposer la formule. En effet jusqu’à 30V elle est linéaire croissante suivent l’équation :

Puis après 30V elle devient quadratique décroissante suivent la formule :

En effet la formule E = V * N * Δw néglige les pertes. Celles-ci deviennent plus importante a chaque augmentation de la tension d’alimentation.

On obtient donc un point de fonctionnement optimal a 30V pour notre système. Ce qui impose que notre système soit équipé d’une source de tension en conséquence.

===Semaine 18 (08/02/2016)===
===Semaine 19 (15/02/2016)===
===Semaine 20 (22/02/2016)===

== Annexes ==

Consommation du STM32L4 Series : http://www.st.com/web/en/catalog/mmc/FM141/SC1169/SS1580?sc=stm32l4

Réduction de la consommation de l'Arduino : http://www.home-automation-community.com/arduino-low-power-how-to-run-atmega328p-for-a-year-on-coin-cell-battery/

Consommation Raspberry : https://www.raspberrypi.org/help/faqs/

Module BLE : http://redbearlab.com/blemini/

Accéléromètre : http://fr.farnell.com/analog-devices/adxl345bccz/accelerometre-3-axes-14lga/dp/1853935

Capteur température : http://fr.farnell.com/analog-devices/tmp36gt9z/capteur-temp-to-92-3/dp/1438760?ost=TMP36GT9Z
ou http://fr.farnell.com/stmicroelectronics/stlm20w87f/capteur-de-temperature-analog/dp/1391131

Accéléromètre + Gyroscope : http://fr.farnell.com/invensense/mpu-6050/gyroscope-accelero-6-axes-i2c/dp/1864742

Altimètre : http://fr.farnell.com/freescale-semiconductor/mpl3115a2/pressure-sensor-20-110kpa-8lga/dp/2009084?ost=MPL3115A2&categoryId=700000004367

Explications norme BLE : chapters.comsoc.org/vancouver/BTLER3.pdf

http://www.argenox.com/bluetooth-low-energy-ble-v4-0-development/library/a-ble-advertising-primer/

== Rapport de Mi-projet ==

[[Fichier:CR_Miprojet_Sultana.pdf‎ ]]

P32 Récupération d'énergie pour balise BLE

2016-02-10T15:37:39Z

Qsultana : /* Semaine 17 (01/02/2016) */

== Objectif ==

Mon projet consiste à réaliser un système électronique autonome, composé de différents capteurs et capable de recueillir et de transmettre les données mémorisées vers un système centralisé.

== Etude préalable ==

L’énergie est le point de difficulté dans la réalisation de ce projet. Chaque élément devra être choisi non seulement pour ses performances mais également pour sa faible consommation.

== Organisation générale ==

Le système est organisé autour d’une source d’énergie, d’un contrôleur, de capteurs, de mémoire et d’un protocole de communication.

On cherche à minimiser l'énergie consommée par l'ensemble du système.

[[Fichier:P32Ensemble.PNG|250px|thumb|left|'''Architecture''']]

=== Chaine de l’énergie ===

L’énergie pour ce module autonome est constituée de quatre phases importantes :

[[Fichier:P32Energie.PNG]]

==== La récupération de l'énergie dans l'environnement ====

Il existe de nombreux moyens pour récupérer de l'énergie dans l'environnement. L'objectif est de trouver les sources les plus adaptées à l'environnement de l'application recherchée.

On peut citer:

* La récupération de l'énergie par différence de température

* Les panneaux photovoltaïques

* La récupération de l'énergie des ondes radio

* La Piézoélectricité

Dans ce projet nous utiliserons la piézoélectricité, le module de récupération ayant déjà fait partie d'une étude de IRCICA précédent le projet.

==== Le stockage de l’énergie ====

Le choix du système de stockage de l'énergie constitue une partie importante de la réalisation du système.
La problématique de cette partie sera de déterminer quel type de stockage nous utiliserons : batterie, super-capacité ou un hybride et de les dimensionner.
Il faudra tenir compte des problèmes de décharge partielle influent sur la durée de vie du stockage.

==== Le management/mise en forme de l’énergie ====

L'objectif de cette partie est d'étudier la nécessité de la mise en place d'une régulation tout en préservant des contraintes de consommation très faibles.

==== L'utilisation de l'énergie mise en forme ====

On cherche à minimiser l'énergie consommée par l'ensemble du système.

=== Contrôleur ===

Le microprocesseur : il existe différents types de microprocesseurs. L'objectif est de choisir un support capable de consommer un minimum d'énergie tout en conservant une taille minimale. Nous avons déjà utilisé dans d'autres projets des micro-contrôleurs de type Arduino et Raspberry pie. Ceux-ci ont pour avantage d’être prêts à l'emploi et faciles de prise en main. On peut s’orienter également vers un contrôleur ultra low power comme le STM32L4.

{| class="wikitable centre" width="80%"
|+
|-
! scope=col |
! scope=col | Consommation
! scope=col | Facilité de développement
! scope=col | Miniaturisation
|-
| width="33%" |
<center>Arduino</center>
| width="34%" |
<center>faible à très faible</center>
| width="33%" |
<center>bonne</center>
| width="33%" |
<center>faible</center>
|-
| width="33%" |
<center>Raspberry pi</center>
| width="34%" |
<center>importante</center>
| width="34%" |
<center>très bonne</center>
| width="34%" |
<center>très faible</center>
|-
| width="33%" |
<center>Ultra low power</center>
| width="34%" |
<center>très, très faible</center>
| width="33%" |
<center>difficile</center>
| width="33%" |
<center>forte</center>
|}

=== Capteurs ===

On peut imaginer différents types de capteurs :

* Accéléromètre

* Gyroscope

* Pression atmosphérique et altitude

* Température

* GPS

=== Mémoire ===

Le système doit être autonome et donc conserver un minimum de mesures pour les cas où la connexion est impossible. La mémoire doit être dimensionnée en fonction du nombre de capteurs, l’intervalle d’acquisition et le temps maximum avant connexion au système centralisé.

=== Protocole de communication ===

Un protocole de communication : dans un premier temps, nous nous concentrons sur le protocole BLE (Bluetooth Low Energie). Ce protocole étant standardisé, il nous permettra de recueillir de la documentation et réaliser des tests de consommation rapides.

== Planning prévisionnel ==

[[Fichier:P32Gant.PNG]]

==Suivi de l'avancement du Projet==
===Semaine 1 (28/09/2015)===

* Rencontre avec Monsieur Boe et Monsieur Giraud

* Présentation du projet

* Recherche documentaire

* Etablissement du cahier des charges

===Semaine 2 (05/10/2015)===

Recherche documentaire sur la consommation estimée des différents éléments.

{| class="wikitable centre" width="80%"
|+
|-
! scope=col | '''Contrôleur'''
! scope=col | Consommation Active
! scope=col | Consommation Inactive
! scope=col | Prix
|-
| width="33%" |
<center>Arduino Pro Mini 328 </center>
| width="34%" |
<center> 7mA (1 capteur)</center>
| width="33%" |
<center>4.5µA</center>
| width="33%" |
<center>Disponible</center>
|-
| width="33%" |
<center>STM32L4 Series (STM32L476JE)</center>
| width="34%" |
<center> 100 μA/MHz</center>
| width="33%" |
<center>120 nA</center>
| width="33%" |
<center>$5</center>
|-
| width="33%" |
<center>Raspberry</center>
| width="34%" |
<center> 200mA </center>
| width="33%" |
<center>200mA</center>
| width="33%" |
<center>Disponible</center>
|}

{| class="wikitable centre" width="80%"
|+
|-
! scope=col | '''Module BLE'''
! scope=col | Consommation
! scope=col | Options d'alimentation
! scope=col | Prix
|-
| width="33%" |
<center>BLE Mini</center>
| width="34%" |
<center> 15 mA </center>
| width="33%" |
<center>3.4V à 11V VIN / 5V USB / Coin Cell Battery (2025 or 2032) / 3.7V Li-ion Battery</center>
| width="33%" |
<center>$17</center>
|}

* <s> Le système Mini Arduino/ BLE Mini me semble être un bon compromis entre facilité d’intégration, consommation d'énergie et miniaturisation du système.</s> (Choix à discuter à la réunion du Merdredi 07/10)
* Choix du module RFduino

{| class="wikitable centre" width="80%"
|+
|-
! scope=col | '''Capteurs'''
! scope=col | Modèle
! scope=col | Alimentation min/max
! scope=col | Prix
|-
| width="33%" |
<center>Température</center>
| width="34%" |
<center> TMP36GT9Z </center>
| width="33%" |
<center>2.7V/5.5V</center>
| width="33%" |
<center>1,46 €</center>
|-
| width="33%" |
<center>Accéléromètre</center>
| width="34%" |
<center> ADXL345BCCZ </center>
| width="33%" |
<center>2V/3.6V</center>
| width="33%" |
<center>5,54 €</center>
|-
| width="33%" |
<center>Gyroscope+Accéléromètre</center>
| width="34%" |
<center> MPU-6050</center>
| width="33%" |
<center>2.5V/3.6V</center>
| width="33%" |
<center>15,73 €</center>
|-
| width="33%" |
<center>Pression atmosphérique / Altitude</center>
| width="34%" |
<center> MPL3115A2 </center>
| width="33%" |
<center>1.95V/3.6V</center>
| width="33%" |
<center>2,65 €</center>
|}

* Pour minimiser les pertes on cherche a travailler avec une tension d'alimentation la plus faible possible. Je propose de travailler avec une tension d'alimentation de 3,3V (Validé à discuter à la réunion du Merdredi 07/10)

* Le système de récupération d'énergie fonctionnant sur la base d'un mouvement, j'ai choisi l'ensemble des capteur ci dessus qui me semble être adapté à l'intégration dans un système en mouvement. (Validé à discuter à la réunion du Merdredi 07/10)

* Récupération des modules RFduino, prise en main

===Semaine 3 (12/10/2015)===

* Installation des librairies

* Visualisation d'exemples

* Tests d'implantation du code source du projet P14: Aimant intelligent de la session IMA4: 2014/2015

* Optimisation du code pour la réduction de la consommation d'énergie

* Recherches sur d'autres composants dans l'optique d'une consommation toujours plus faible

{| class="wikitable centre" width="80%"
|+
|-
! scope=col | '''Capteurs'''
! scope=col | Modèle
! scope=col | Alimentation min/max
! scope=col | Prix
! scope=col | Consommation (typ/max)
|-
| width="33%" |
<center>Température</center>
| width="34%" |
<center> STLM20W87F </center>
| width="33%" |
<center>2.4V/5.5V</center>
| width="33%" |
<center> 0,775 € </center>
| width="33%" |
<center> 4.8 μA/8.0 μA </center>
|}

'''Calcul théorique de la consommation énergétique du module BLE + RFD22301'''

Mode "endormi" : ARM CPU Running Current + Output standard drive current = 4 + 0.5 = 4.5mA

Mode "acquisition": ARM CPU Running Current + Output high drive current = 5 + 4 = 9mA

Mode "transmission" : ARM CPU Running Current + Transmit Current + Output standard drive current = 4 + 0.5 + 12 = 16.5mA

http://www.rfduino.com/wp-content/uploads/2014/03/RFD22301.Data_.Sheet_.11.24.13_11.38PM.pdf

'''Code possible du mode "endormi"'''

pinMode(5, INPUT);
RFduino_pinWake(5, HIGH);

RFduino_ULPDelay(INFINITE);
if (RFduino_pinWoke(5))
{
state = ! state;
RFduinoGZLL.sendToHost(state);
}

http://forum.rfduino.com/index.php?topic=385.0

===Semaine 4 (19/10/2015)===

* Réunion du 21/10

* Réalisation de tests

* Ajustement du nombre de capteurs : dans un premier temps on utilisera le capteur de température puis l'accéléromètre

* Discussion sur le bac de test et méthodes de test : résistance de visualisation, chronométrage du temps de transmission, vitesse du processeur

* Réalisation des premiers relevés

===Semaine 5 (26/10/2015)===

* Recherche bibliographique sur les modes d'endormissement du module RFduino

* Essais de codes utilisant un mode d'endormissement plus profond

* Réalisation de graphique de l'énergie utilisée par le module lors de la transmission d'un message par le module BLE.

* Recherches sur des méthodes de programmation pour la diminution de la vitesse processeur

[[Fichier:P32Montage.jpg|250px|thumb|left|'''Montage de test''']]
[[Fichier:P32resultats.jpg|250px|thumb|center|'''Visualisation du courant consommé lors d'envoi toutes les 10ms''']]

* On visualise à l'oscilloscope des pic d'envoi et des pic d'avertissement de la balise BLE, on peut ainsi déduire la puissance nécessaire de chaque action

===Semaine 6 (02/11/2015)===

* Test de diminution de la vitesse processeur

* Réalisation de graphique démontrant l'impact de la réduction de la vitesse processeur sur l'énergie consommée et déduction d'une vitesse optimale pour notre application

* Réunion du 4/11

Définition d'objectifs : Création d'un fichier excel permettant de caractériser les coûts en énergies de chaque étapes de fonctionnement du système.

* Création d'un environnement de test "normé" ( Pour éviter les variations de mesures on réalise un banc et on applique les mêmes conditions de test pour chaque essai)

* Recherche bibliographique sur la norme BLE : recherche du temps maximum entre deux "avertissements" de la balise BLE

===Semaine 7 (09/11/2015)===
* Explication du principe de communication BLE pour l'exploitation des résultats

[[Fichier:Freq.PNG]]

Nous nous intéressons dans notre projet à "l'observateur". Cet objet peut avoir trois états : stand-by, advertising et en communication.

[[Fichier:Brod2.png]]

Dans le mode "Advertising" le système peut :

- Avertir le système récepteur de la proximité d'un capteur

- Avertir de la présence à un appareil souhaitant ce connecter

- Ce reconnecter de façon asynchrone

===Semaine 8 (16/11/2015)===

Analyse en détail d'une trame BLE

[[Fichier:Com.PNG]]

On constate que pendant la durée de la trame il y a un échange entre les deux objets appairé. On s’intéresse ici uniquement aux actions "Slave Tx". Le but étant d'identifier la durée et le courant consommé par ces actions pour obtenir des valeurs en joules.

[[Fichier:SchemaCom.PNG]]

On constate donc deux phases :

- Advertising event

- Connexion event

Nous allons essayer de retrouver et quantifié l'énergie consommé dans ces deux phases.

===Semaine 9 (23/11/2015)===

Lors de cette semaine nous avons effectué des tests en respectant une procédure de test précise. En effet les valeurs des courants que nous relevons sont très petites aussi chaque variation du montage est susceptible de perturber les valeurs.

[[Fichier:P32Conne.jpg|250px|thumb|left|'''Phase connexion''']]

[[Fichier:Avertissement.jpg|250px|thumb|center|'''Phase Advertising''']]

===Semaine 10 (30/11/2015)===

- On cherche a diminuer légèrement la consommation par des modifications logiciel :

Réduction de la puissance de la radio BLE : Diminution de la portée

Augmentation de la fréquence d'advertising : tant que la fréquence d'advetising est inférieure a cette de relevé des capteurs on s'assure que la donnée envoyée est toujours mise à jour.

[[Fichier:Pwl20-envoi.jpg|250px|thumb|left|'''Avec modification logiciel''']]

[[Fichier:Sans-pwlvl.jpg|250px|thumb|center|'''Sans modification logiciel''']]

- On concentre nos résultats dans un tableau récapitulatif en vue du dimensionnement de la batterie du système

[[Fichier:P32tbresul.PNG]]

===Semaine 11 (07/12/2015)===

Tests d'intégration de plusieurs capteur et observations des modification de la consommation des ADC et de la durée/consommation de la transmission.

Réunion de vérification des tests.

Mise en évidence de la dualité consommation d'énergie - Temps de réponse du système

En effet chaque "Advertisement" consomme une quantité d'énergie nous pouvons gérer l'espacement entre ceux-ci mais plus ce temps serra élevé plus il faudra de temps pour ce connecter à ce périphérique.

* Rédaction d'un rapport de test

* Rédaction du rapport de pré soutenance

===Semaine 12 (14/12/2015)===
===Semaine 13 (04/01/2016)===

*Amélioration du modèle

L’amélioration du modèle est réalisée en tenant compte des facteurs influent sur la qualité de la transmission.
Ainsi grâce a un pico scope utilisé à l’IRCICA j’ai pu relever de nombreux échantillons nécessaire a une étude statistique des surcoûts en énergie.

===Semaine 14 (11/01/2016)===
===Semaine 15 (18/01/2016)===

Principe de fonctionnement du récupérateur d’énergie

Le récupérateur d’énergie fonctionne grâce à un patch piezo. Ce patch est capable de produire un courent à partir de la vélocité d’une impulsion suivent la formule :

[[Fichier:Equapiezo.PNG]]

[[Fichier:Modelepizo.PNG|250px|thumb|left|'''Modèle simplifié du patch piezo''']]

Pour récupérer de l’énergie il est couplé au système suivent :

[[Fichier:montagepiezo.PNG]]

La puissance du système est définie par :

P=V*im

L’énergie s’exprime alors :

[[Fichier:Equaenergie.PNG]]

L’énergie produite par le système est donc dépendante de la tension d’alimentation V de la constante électromécanique N et du choc produit sur le patch piezo.
Une impulsion sur le capteur piezo est de la forme :

La dérivée par rapport au temps de cette impulsion est donc de la forme :

Il est donc important de « fenêtrer » la tension pour ne récupérer que la partie positive.
Ce fenêtrage ainsi que la fréquence de commutation du hacheur est assurée par un microcontrôleur.

Dans la suite de notre étude nous ne tiendrons pas compte de la consommation de celui-ci.

===Semaine 16 (25/01/2016)===
===Semaine 17 (01/02/2016)===

Test de la quantité d’énergie récupérée par un patch piezo

Méthodologie :

Channel rouge : Tension aux bornes du patch piezo. Ici on observe une fenêtre de tension de 4,5ms imposée par le microcontrôleur.

Channel vert : Tension aux bornes de la capacité C1 de 220nF

[[Fichier:Diffpot.png]]

On constate qu’un choc sur le patch piezo produit une énergie suivent la formule, E = V * N * Δw
N étant une constante électromécanique, on va faire varier V pour évaluer le gain en énergie. Cependant Δw est généré par un choc d’un stylo sur le patch il n’est donc pas uniforme.
Nous utilisons donc une méthode statistique qui consiste à retirer deux extrémum et faire la moyenne de 10 mesures.

Nous obtenons la courbe suivante :

On constate que la courbe n’est pas linéaire comme l’aurai laissé supposer la formule. En effet jusqu’à 30V elle est linéaire croissante suivent l’équation :

Puis après 30V elle devient quadratique décroissante suivent la formule :

En effet la formule E = V * N * Δw néglige les pertes. Celles-ci deviennent plus importante a chaque augmentation de la tension d’alimentation.

On obtient donc un point de fonctionnement optimal a 30V pour notre système. Ce qui impose que notre système soit équipé d’une source de tension en conséquence.

===Semaine 18 (08/02/2016)===
===Semaine 19 (15/02/2016)===
===Semaine 20 (22/02/2016)===

== Annexes ==

Consommation du STM32L4 Series : http://www.st.com/web/en/catalog/mmc/FM141/SC1169/SS1580?sc=stm32l4

Réduction de la consommation de l'Arduino : http://www.home-automation-community.com/arduino-low-power-how-to-run-atmega328p-for-a-year-on-coin-cell-battery/

Consommation Raspberry : https://www.raspberrypi.org/help/faqs/

Module BLE : http://redbearlab.com/blemini/

Accéléromètre : http://fr.farnell.com/analog-devices/adxl345bccz/accelerometre-3-axes-14lga/dp/1853935

Capteur température : http://fr.farnell.com/analog-devices/tmp36gt9z/capteur-temp-to-92-3/dp/1438760?ost=TMP36GT9Z
ou http://fr.farnell.com/stmicroelectronics/stlm20w87f/capteur-de-temperature-analog/dp/1391131

Accéléromètre + Gyroscope : http://fr.farnell.com/invensense/mpu-6050/gyroscope-accelero-6-axes-i2c/dp/1864742

Altimètre : http://fr.farnell.com/freescale-semiconductor/mpl3115a2/pressure-sensor-20-110kpa-8lga/dp/2009084?ost=MPL3115A2&categoryId=700000004367

Explications norme BLE : chapters.comsoc.org/vancouver/BTLER3.pdf

http://www.argenox.com/bluetooth-low-energy-ble-v4-0-development/library/a-ble-advertising-primer/

== Rapport de Mi-projet ==

[[Fichier:CR_Miprojet_Sultana.pdf‎ ]]

Fichier:Diffpot.png

2016-02-10T15:37:12Z

Qsultana : P32 : Tests sur le piezo

P32 : Tests sur le piezo

P32 Récupération d'énergie pour balise BLE

2016-02-10T15:34:49Z

Qsultana : /* Semaine 15 (18/01/2016) */

== Objectif ==

Mon projet consiste à réaliser un système électronique autonome, composé de différents capteurs et capable de recueillir et de transmettre les données mémorisées vers un système centralisé.

== Etude préalable ==

L’énergie est le point de difficulté dans la réalisation de ce projet. Chaque élément devra être choisi non seulement pour ses performances mais également pour sa faible consommation.

== Organisation générale ==

Le système est organisé autour d’une source d’énergie, d’un contrôleur, de capteurs, de mémoire et d’un protocole de communication.

On cherche à minimiser l'énergie consommée par l'ensemble du système.

[[Fichier:P32Ensemble.PNG|250px|thumb|left|'''Architecture''']]

=== Chaine de l’énergie ===

L’énergie pour ce module autonome est constituée de quatre phases importantes :

[[Fichier:P32Energie.PNG]]

==== La récupération de l'énergie dans l'environnement ====

Il existe de nombreux moyens pour récupérer de l'énergie dans l'environnement. L'objectif est de trouver les sources les plus adaptées à l'environnement de l'application recherchée.

On peut citer:

* La récupération de l'énergie par différence de température

* Les panneaux photovoltaïques

* La récupération de l'énergie des ondes radio

* La Piézoélectricité

Dans ce projet nous utiliserons la piézoélectricité, le module de récupération ayant déjà fait partie d'une étude de IRCICA précédent le projet.

==== Le stockage de l’énergie ====

Le choix du système de stockage de l'énergie constitue une partie importante de la réalisation du système.
La problématique de cette partie sera de déterminer quel type de stockage nous utiliserons : batterie, super-capacité ou un hybride et de les dimensionner.
Il faudra tenir compte des problèmes de décharge partielle influent sur la durée de vie du stockage.

==== Le management/mise en forme de l’énergie ====

L'objectif de cette partie est d'étudier la nécessité de la mise en place d'une régulation tout en préservant des contraintes de consommation très faibles.

==== L'utilisation de l'énergie mise en forme ====

On cherche à minimiser l'énergie consommée par l'ensemble du système.

=== Contrôleur ===

Le microprocesseur : il existe différents types de microprocesseurs. L'objectif est de choisir un support capable de consommer un minimum d'énergie tout en conservant une taille minimale. Nous avons déjà utilisé dans d'autres projets des micro-contrôleurs de type Arduino et Raspberry pie. Ceux-ci ont pour avantage d’être prêts à l'emploi et faciles de prise en main. On peut s’orienter également vers un contrôleur ultra low power comme le STM32L4.

{| class="wikitable centre" width="80%"
|+
|-
! scope=col |
! scope=col | Consommation
! scope=col | Facilité de développement
! scope=col | Miniaturisation
|-
| width="33%" |
<center>Arduino</center>
| width="34%" |
<center>faible à très faible</center>
| width="33%" |
<center>bonne</center>
| width="33%" |
<center>faible</center>
|-
| width="33%" |
<center>Raspberry pi</center>
| width="34%" |
<center>importante</center>
| width="34%" |
<center>très bonne</center>
| width="34%" |
<center>très faible</center>
|-
| width="33%" |
<center>Ultra low power</center>
| width="34%" |
<center>très, très faible</center>
| width="33%" |
<center>difficile</center>
| width="33%" |
<center>forte</center>
|}

=== Capteurs ===

On peut imaginer différents types de capteurs :

* Accéléromètre

* Gyroscope

* Pression atmosphérique et altitude

* Température

* GPS

=== Mémoire ===

Le système doit être autonome et donc conserver un minimum de mesures pour les cas où la connexion est impossible. La mémoire doit être dimensionnée en fonction du nombre de capteurs, l’intervalle d’acquisition et le temps maximum avant connexion au système centralisé.

=== Protocole de communication ===

Un protocole de communication : dans un premier temps, nous nous concentrons sur le protocole BLE (Bluetooth Low Energie). Ce protocole étant standardisé, il nous permettra de recueillir de la documentation et réaliser des tests de consommation rapides.

== Planning prévisionnel ==

[[Fichier:P32Gant.PNG]]

==Suivi de l'avancement du Projet==
===Semaine 1 (28/09/2015)===

* Rencontre avec Monsieur Boe et Monsieur Giraud

* Présentation du projet

* Recherche documentaire

* Etablissement du cahier des charges

===Semaine 2 (05/10/2015)===

Recherche documentaire sur la consommation estimée des différents éléments.

{| class="wikitable centre" width="80%"
|+
|-
! scope=col | '''Contrôleur'''
! scope=col | Consommation Active
! scope=col | Consommation Inactive
! scope=col | Prix
|-
| width="33%" |
<center>Arduino Pro Mini 328 </center>
| width="34%" |
<center> 7mA (1 capteur)</center>
| width="33%" |
<center>4.5µA</center>
| width="33%" |
<center>Disponible</center>
|-
| width="33%" |
<center>STM32L4 Series (STM32L476JE)</center>
| width="34%" |
<center> 100 μA/MHz</center>
| width="33%" |
<center>120 nA</center>
| width="33%" |
<center>$5</center>
|-
| width="33%" |
<center>Raspberry</center>
| width="34%" |
<center> 200mA </center>
| width="33%" |
<center>200mA</center>
| width="33%" |
<center>Disponible</center>
|}

{| class="wikitable centre" width="80%"
|+
|-
! scope=col | '''Module BLE'''
! scope=col | Consommation
! scope=col | Options d'alimentation
! scope=col | Prix
|-
| width="33%" |
<center>BLE Mini</center>
| width="34%" |
<center> 15 mA </center>
| width="33%" |
<center>3.4V à 11V VIN / 5V USB / Coin Cell Battery (2025 or 2032) / 3.7V Li-ion Battery</center>
| width="33%" |
<center>$17</center>
|}

* <s> Le système Mini Arduino/ BLE Mini me semble être un bon compromis entre facilité d’intégration, consommation d'énergie et miniaturisation du système.</s> (Choix à discuter à la réunion du Merdredi 07/10)
* Choix du module RFduino

{| class="wikitable centre" width="80%"
|+
|-
! scope=col | '''Capteurs'''
! scope=col | Modèle
! scope=col | Alimentation min/max
! scope=col | Prix
|-
| width="33%" |
<center>Température</center>
| width="34%" |
<center> TMP36GT9Z </center>
| width="33%" |
<center>2.7V/5.5V</center>
| width="33%" |
<center>1,46 €</center>
|-
| width="33%" |
<center>Accéléromètre</center>
| width="34%" |
<center> ADXL345BCCZ </center>
| width="33%" |
<center>2V/3.6V</center>
| width="33%" |
<center>5,54 €</center>
|-
| width="33%" |
<center>Gyroscope+Accéléromètre</center>
| width="34%" |
<center> MPU-6050</center>
| width="33%" |
<center>2.5V/3.6V</center>
| width="33%" |
<center>15,73 €</center>
|-
| width="33%" |
<center>Pression atmosphérique / Altitude</center>
| width="34%" |
<center> MPL3115A2 </center>
| width="33%" |
<center>1.95V/3.6V</center>
| width="33%" |
<center>2,65 €</center>
|}

* Pour minimiser les pertes on cherche a travailler avec une tension d'alimentation la plus faible possible. Je propose de travailler avec une tension d'alimentation de 3,3V (Validé à discuter à la réunion du Merdredi 07/10)

* Le système de récupération d'énergie fonctionnant sur la base d'un mouvement, j'ai choisi l'ensemble des capteur ci dessus qui me semble être adapté à l'intégration dans un système en mouvement. (Validé à discuter à la réunion du Merdredi 07/10)

* Récupération des modules RFduino, prise en main

===Semaine 3 (12/10/2015)===

* Installation des librairies

* Visualisation d'exemples

* Tests d'implantation du code source du projet P14: Aimant intelligent de la session IMA4: 2014/2015

* Optimisation du code pour la réduction de la consommation d'énergie

* Recherches sur d'autres composants dans l'optique d'une consommation toujours plus faible

{| class="wikitable centre" width="80%"
|+
|-
! scope=col | '''Capteurs'''
! scope=col | Modèle
! scope=col | Alimentation min/max
! scope=col | Prix
! scope=col | Consommation (typ/max)
|-
| width="33%" |
<center>Température</center>
| width="34%" |
<center> STLM20W87F </center>
| width="33%" |
<center>2.4V/5.5V</center>
| width="33%" |
<center> 0,775 € </center>
| width="33%" |
<center> 4.8 μA/8.0 μA </center>
|}

'''Calcul théorique de la consommation énergétique du module BLE + RFD22301'''

Mode "endormi" : ARM CPU Running Current + Output standard drive current = 4 + 0.5 = 4.5mA

Mode "acquisition": ARM CPU Running Current + Output high drive current = 5 + 4 = 9mA

Mode "transmission" : ARM CPU Running Current + Transmit Current + Output standard drive current = 4 + 0.5 + 12 = 16.5mA

http://www.rfduino.com/wp-content/uploads/2014/03/RFD22301.Data_.Sheet_.11.24.13_11.38PM.pdf

'''Code possible du mode "endormi"'''

pinMode(5, INPUT);
RFduino_pinWake(5, HIGH);

RFduino_ULPDelay(INFINITE);
if (RFduino_pinWoke(5))
{
state = ! state;
RFduinoGZLL.sendToHost(state);
}

http://forum.rfduino.com/index.php?topic=385.0

===Semaine 4 (19/10/2015)===

* Réunion du 21/10

* Réalisation de tests

* Ajustement du nombre de capteurs : dans un premier temps on utilisera le capteur de température puis l'accéléromètre

* Discussion sur le bac de test et méthodes de test : résistance de visualisation, chronométrage du temps de transmission, vitesse du processeur

* Réalisation des premiers relevés

===Semaine 5 (26/10/2015)===

* Recherche bibliographique sur les modes d'endormissement du module RFduino

* Essais de codes utilisant un mode d'endormissement plus profond

* Réalisation de graphique de l'énergie utilisée par le module lors de la transmission d'un message par le module BLE.

* Recherches sur des méthodes de programmation pour la diminution de la vitesse processeur

[[Fichier:P32Montage.jpg|250px|thumb|left|'''Montage de test''']]
[[Fichier:P32resultats.jpg|250px|thumb|center|'''Visualisation du courant consommé lors d'envoi toutes les 10ms''']]

* On visualise à l'oscilloscope des pic d'envoi et des pic d'avertissement de la balise BLE, on peut ainsi déduire la puissance nécessaire de chaque action

===Semaine 6 (02/11/2015)===

* Test de diminution de la vitesse processeur

* Réalisation de graphique démontrant l'impact de la réduction de la vitesse processeur sur l'énergie consommée et déduction d'une vitesse optimale pour notre application

* Réunion du 4/11

Définition d'objectifs : Création d'un fichier excel permettant de caractériser les coûts en énergies de chaque étapes de fonctionnement du système.

* Création d'un environnement de test "normé" ( Pour éviter les variations de mesures on réalise un banc et on applique les mêmes conditions de test pour chaque essai)

* Recherche bibliographique sur la norme BLE : recherche du temps maximum entre deux "avertissements" de la balise BLE

===Semaine 7 (09/11/2015)===
* Explication du principe de communication BLE pour l'exploitation des résultats

[[Fichier:Freq.PNG]]

Nous nous intéressons dans notre projet à "l'observateur". Cet objet peut avoir trois états : stand-by, advertising et en communication.

[[Fichier:Brod2.png]]

Dans le mode "Advertising" le système peut :

- Avertir le système récepteur de la proximité d'un capteur

- Avertir de la présence à un appareil souhaitant ce connecter

- Ce reconnecter de façon asynchrone

===Semaine 8 (16/11/2015)===

Analyse en détail d'une trame BLE

[[Fichier:Com.PNG]]

On constate que pendant la durée de la trame il y a un échange entre les deux objets appairé. On s’intéresse ici uniquement aux actions "Slave Tx". Le but étant d'identifier la durée et le courant consommé par ces actions pour obtenir des valeurs en joules.

[[Fichier:SchemaCom.PNG]]

On constate donc deux phases :

- Advertising event

- Connexion event

Nous allons essayer de retrouver et quantifié l'énergie consommé dans ces deux phases.

===Semaine 9 (23/11/2015)===

Lors de cette semaine nous avons effectué des tests en respectant une procédure de test précise. En effet les valeurs des courants que nous relevons sont très petites aussi chaque variation du montage est susceptible de perturber les valeurs.

[[Fichier:P32Conne.jpg|250px|thumb|left|'''Phase connexion''']]

[[Fichier:Avertissement.jpg|250px|thumb|center|'''Phase Advertising''']]

===Semaine 10 (30/11/2015)===

- On cherche a diminuer légèrement la consommation par des modifications logiciel :

Réduction de la puissance de la radio BLE : Diminution de la portée

Augmentation de la fréquence d'advertising : tant que la fréquence d'advetising est inférieure a cette de relevé des capteurs on s'assure que la donnée envoyée est toujours mise à jour.

[[Fichier:Pwl20-envoi.jpg|250px|thumb|left|'''Avec modification logiciel''']]

[[Fichier:Sans-pwlvl.jpg|250px|thumb|center|'''Sans modification logiciel''']]

- On concentre nos résultats dans un tableau récapitulatif en vue du dimensionnement de la batterie du système

[[Fichier:P32tbresul.PNG]]

===Semaine 11 (07/12/2015)===

Tests d'intégration de plusieurs capteur et observations des modification de la consommation des ADC et de la durée/consommation de la transmission.

Réunion de vérification des tests.

Mise en évidence de la dualité consommation d'énergie - Temps de réponse du système

En effet chaque "Advertisement" consomme une quantité d'énergie nous pouvons gérer l'espacement entre ceux-ci mais plus ce temps serra élevé plus il faudra de temps pour ce connecter à ce périphérique.

* Rédaction d'un rapport de test

* Rédaction du rapport de pré soutenance

===Semaine 12 (14/12/2015)===
===Semaine 13 (04/01/2016)===

*Amélioration du modèle

L’amélioration du modèle est réalisée en tenant compte des facteurs influent sur la qualité de la transmission.
Ainsi grâce a un pico scope utilisé à l’IRCICA j’ai pu relever de nombreux échantillons nécessaire a une étude statistique des surcoûts en énergie.

===Semaine 14 (11/01/2016)===
===Semaine 15 (18/01/2016)===

Principe de fonctionnement du récupérateur d’énergie

Le récupérateur d’énergie fonctionne grâce à un patch piezo. Ce patch est capable de produire un courent à partir de la vélocité d’une impulsion suivent la formule :

[[Fichier:Equapiezo.PNG]]

[[Fichier:Modelepizo.PNG|250px|thumb|left|'''Modèle simplifié du patch piezo''']]

Pour récupérer de l’énergie il est couplé au système suivent :

[[Fichier:montagepiezo.PNG]]

La puissance du système est définie par :

P=V*im

L’énergie s’exprime alors :

[[Fichier:Equaenergie.PNG]]

L’énergie produite par le système est donc dépendante de la tension d’alimentation V de la constante électromécanique N et du choc produit sur le patch piezo.
Une impulsion sur le capteur piezo est de la forme :

La dérivée par rapport au temps de cette impulsion est donc de la forme :

Il est donc important de « fenêtrer » la tension pour ne récupérer que la partie positive.
Ce fenêtrage ainsi que la fréquence de commutation du hacheur est assurée par un microcontrôleur.

Dans la suite de notre étude nous ne tiendrons pas compte de la consommation de celui-ci.

===Semaine 16 (25/01/2016)===
===Semaine 17 (01/02/2016)===
===Semaine 18 (08/02/2016)===
===Semaine 19 (15/02/2016)===
===Semaine 20 (22/02/2016)===

== Annexes ==

Consommation du STM32L4 Series : http://www.st.com/web/en/catalog/mmc/FM141/SC1169/SS1580?sc=stm32l4

Réduction de la consommation de l'Arduino : http://www.home-automation-community.com/arduino-low-power-how-to-run-atmega328p-for-a-year-on-coin-cell-battery/

Consommation Raspberry : https://www.raspberrypi.org/help/faqs/

Module BLE : http://redbearlab.com/blemini/

Accéléromètre : http://fr.farnell.com/analog-devices/adxl345bccz/accelerometre-3-axes-14lga/dp/1853935

Capteur température : http://fr.farnell.com/analog-devices/tmp36gt9z/capteur-temp-to-92-3/dp/1438760?ost=TMP36GT9Z
ou http://fr.farnell.com/stmicroelectronics/stlm20w87f/capteur-de-temperature-analog/dp/1391131

Accéléromètre + Gyroscope : http://fr.farnell.com/invensense/mpu-6050/gyroscope-accelero-6-axes-i2c/dp/1864742

Altimètre : http://fr.farnell.com/freescale-semiconductor/mpl3115a2/pressure-sensor-20-110kpa-8lga/dp/2009084?ost=MPL3115A2&categoryId=700000004367

Explications norme BLE : chapters.comsoc.org/vancouver/BTLER3.pdf

http://www.argenox.com/bluetooth-low-energy-ble-v4-0-development/library/a-ble-advertising-primer/

== Rapport de Mi-projet ==

[[Fichier:CR_Miprojet_Sultana.pdf‎ ]]

Fichier:Equaenergie.PNG

2016-02-10T15:34:05Z

Qsultana : P32 : Équation énergétique piezo

P32 : Équation énergétique piezo

P32 Récupération d'énergie pour balise BLE

2016-02-10T15:32:55Z

Qsultana : /* Semaine 15 (18/01/2016) */

== Objectif ==

Mon projet consiste à réaliser un système électronique autonome, composé de différents capteurs et capable de recueillir et de transmettre les données mémorisées vers un système centralisé.

== Etude préalable ==

L’énergie est le point de difficulté dans la réalisation de ce projet. Chaque élément devra être choisi non seulement pour ses performances mais également pour sa faible consommation.

== Organisation générale ==

Le système est organisé autour d’une source d’énergie, d’un contrôleur, de capteurs, de mémoire et d’un protocole de communication.

On cherche à minimiser l'énergie consommée par l'ensemble du système.

[[Fichier:P32Ensemble.PNG|250px|thumb|left|'''Architecture''']]

=== Chaine de l’énergie ===

L’énergie pour ce module autonome est constituée de quatre phases importantes :

[[Fichier:P32Energie.PNG]]

==== La récupération de l'énergie dans l'environnement ====

Il existe de nombreux moyens pour récupérer de l'énergie dans l'environnement. L'objectif est de trouver les sources les plus adaptées à l'environnement de l'application recherchée.

On peut citer:

* La récupération de l'énergie par différence de température

* Les panneaux photovoltaïques

* La récupération de l'énergie des ondes radio

* La Piézoélectricité

Dans ce projet nous utiliserons la piézoélectricité, le module de récupération ayant déjà fait partie d'une étude de IRCICA précédent le projet.

==== Le stockage de l’énergie ====

Le choix du système de stockage de l'énergie constitue une partie importante de la réalisation du système.
La problématique de cette partie sera de déterminer quel type de stockage nous utiliserons : batterie, super-capacité ou un hybride et de les dimensionner.
Il faudra tenir compte des problèmes de décharge partielle influent sur la durée de vie du stockage.

==== Le management/mise en forme de l’énergie ====

L'objectif de cette partie est d'étudier la nécessité de la mise en place d'une régulation tout en préservant des contraintes de consommation très faibles.

==== L'utilisation de l'énergie mise en forme ====

On cherche à minimiser l'énergie consommée par l'ensemble du système.

=== Contrôleur ===

Le microprocesseur : il existe différents types de microprocesseurs. L'objectif est de choisir un support capable de consommer un minimum d'énergie tout en conservant une taille minimale. Nous avons déjà utilisé dans d'autres projets des micro-contrôleurs de type Arduino et Raspberry pie. Ceux-ci ont pour avantage d’être prêts à l'emploi et faciles de prise en main. On peut s’orienter également vers un contrôleur ultra low power comme le STM32L4.

{| class="wikitable centre" width="80%"
|+
|-
! scope=col |
! scope=col | Consommation
! scope=col | Facilité de développement
! scope=col | Miniaturisation
|-
| width="33%" |
<center>Arduino</center>
| width="34%" |
<center>faible à très faible</center>
| width="33%" |
<center>bonne</center>
| width="33%" |
<center>faible</center>
|-
| width="33%" |
<center>Raspberry pi</center>
| width="34%" |
<center>importante</center>
| width="34%" |
<center>très bonne</center>
| width="34%" |
<center>très faible</center>
|-
| width="33%" |
<center>Ultra low power</center>
| width="34%" |
<center>très, très faible</center>
| width="33%" |
<center>difficile</center>
| width="33%" |
<center>forte</center>
|}

=== Capteurs ===

On peut imaginer différents types de capteurs :

* Accéléromètre

* Gyroscope

* Pression atmosphérique et altitude

* Température

* GPS

=== Mémoire ===

Le système doit être autonome et donc conserver un minimum de mesures pour les cas où la connexion est impossible. La mémoire doit être dimensionnée en fonction du nombre de capteurs, l’intervalle d’acquisition et le temps maximum avant connexion au système centralisé.

=== Protocole de communication ===

Un protocole de communication : dans un premier temps, nous nous concentrons sur le protocole BLE (Bluetooth Low Energie). Ce protocole étant standardisé, il nous permettra de recueillir de la documentation et réaliser des tests de consommation rapides.

== Planning prévisionnel ==

[[Fichier:P32Gant.PNG]]

==Suivi de l'avancement du Projet==
===Semaine 1 (28/09/2015)===

* Rencontre avec Monsieur Boe et Monsieur Giraud

* Présentation du projet

* Recherche documentaire

* Etablissement du cahier des charges

===Semaine 2 (05/10/2015)===

Recherche documentaire sur la consommation estimée des différents éléments.

{| class="wikitable centre" width="80%"
|+
|-
! scope=col | '''Contrôleur'''
! scope=col | Consommation Active
! scope=col | Consommation Inactive
! scope=col | Prix
|-
| width="33%" |
<center>Arduino Pro Mini 328 </center>
| width="34%" |
<center> 7mA (1 capteur)</center>
| width="33%" |
<center>4.5µA</center>
| width="33%" |
<center>Disponible</center>
|-
| width="33%" |
<center>STM32L4 Series (STM32L476JE)</center>
| width="34%" |
<center> 100 μA/MHz</center>
| width="33%" |
<center>120 nA</center>
| width="33%" |
<center>$5</center>
|-
| width="33%" |
<center>Raspberry</center>
| width="34%" |
<center> 200mA </center>
| width="33%" |
<center>200mA</center>
| width="33%" |
<center>Disponible</center>
|}

{| class="wikitable centre" width="80%"
|+
|-
! scope=col | '''Module BLE'''
! scope=col | Consommation
! scope=col | Options d'alimentation
! scope=col | Prix
|-
| width="33%" |
<center>BLE Mini</center>
| width="34%" |
<center> 15 mA </center>
| width="33%" |
<center>3.4V à 11V VIN / 5V USB / Coin Cell Battery (2025 or 2032) / 3.7V Li-ion Battery</center>
| width="33%" |
<center>$17</center>
|}

* <s> Le système Mini Arduino/ BLE Mini me semble être un bon compromis entre facilité d’intégration, consommation d'énergie et miniaturisation du système.</s> (Choix à discuter à la réunion du Merdredi 07/10)
* Choix du module RFduino

{| class="wikitable centre" width="80%"
|+
|-
! scope=col | '''Capteurs'''
! scope=col | Modèle
! scope=col | Alimentation min/max
! scope=col | Prix
|-
| width="33%" |
<center>Température</center>
| width="34%" |
<center> TMP36GT9Z </center>
| width="33%" |
<center>2.7V/5.5V</center>
| width="33%" |
<center>1,46 €</center>
|-
| width="33%" |
<center>Accéléromètre</center>
| width="34%" |
<center> ADXL345BCCZ </center>
| width="33%" |
<center>2V/3.6V</center>
| width="33%" |
<center>5,54 €</center>
|-
| width="33%" |
<center>Gyroscope+Accéléromètre</center>
| width="34%" |
<center> MPU-6050</center>
| width="33%" |
<center>2.5V/3.6V</center>
| width="33%" |
<center>15,73 €</center>
|-
| width="33%" |
<center>Pression atmosphérique / Altitude</center>
| width="34%" |
<center> MPL3115A2 </center>
| width="33%" |
<center>1.95V/3.6V</center>
| width="33%" |
<center>2,65 €</center>
|}

* Pour minimiser les pertes on cherche a travailler avec une tension d'alimentation la plus faible possible. Je propose de travailler avec une tension d'alimentation de 3,3V (Validé à discuter à la réunion du Merdredi 07/10)

* Le système de récupération d'énergie fonctionnant sur la base d'un mouvement, j'ai choisi l'ensemble des capteur ci dessus qui me semble être adapté à l'intégration dans un système en mouvement. (Validé à discuter à la réunion du Merdredi 07/10)

* Récupération des modules RFduino, prise en main

===Semaine 3 (12/10/2015)===

* Installation des librairies

* Visualisation d'exemples

* Tests d'implantation du code source du projet P14: Aimant intelligent de la session IMA4: 2014/2015

* Optimisation du code pour la réduction de la consommation d'énergie

* Recherches sur d'autres composants dans l'optique d'une consommation toujours plus faible

{| class="wikitable centre" width="80%"
|+
|-
! scope=col | '''Capteurs'''
! scope=col | Modèle
! scope=col | Alimentation min/max
! scope=col | Prix
! scope=col | Consommation (typ/max)
|-
| width="33%" |
<center>Température</center>
| width="34%" |
<center> STLM20W87F </center>
| width="33%" |
<center>2.4V/5.5V</center>
| width="33%" |
<center> 0,775 € </center>
| width="33%" |
<center> 4.8 μA/8.0 μA </center>
|}

'''Calcul théorique de la consommation énergétique du module BLE + RFD22301'''

Mode "endormi" : ARM CPU Running Current + Output standard drive current = 4 + 0.5 = 4.5mA

Mode "acquisition": ARM CPU Running Current + Output high drive current = 5 + 4 = 9mA

Mode "transmission" : ARM CPU Running Current + Transmit Current + Output standard drive current = 4 + 0.5 + 12 = 16.5mA

http://www.rfduino.com/wp-content/uploads/2014/03/RFD22301.Data_.Sheet_.11.24.13_11.38PM.pdf

'''Code possible du mode "endormi"'''

pinMode(5, INPUT);
RFduino_pinWake(5, HIGH);

RFduino_ULPDelay(INFINITE);
if (RFduino_pinWoke(5))
{
state = ! state;
RFduinoGZLL.sendToHost(state);
}

http://forum.rfduino.com/index.php?topic=385.0

===Semaine 4 (19/10/2015)===

* Réunion du 21/10

* Réalisation de tests

* Ajustement du nombre de capteurs : dans un premier temps on utilisera le capteur de température puis l'accéléromètre

* Discussion sur le bac de test et méthodes de test : résistance de visualisation, chronométrage du temps de transmission, vitesse du processeur

* Réalisation des premiers relevés

===Semaine 5 (26/10/2015)===

* Recherche bibliographique sur les modes d'endormissement du module RFduino

* Essais de codes utilisant un mode d'endormissement plus profond

* Réalisation de graphique de l'énergie utilisée par le module lors de la transmission d'un message par le module BLE.

* Recherches sur des méthodes de programmation pour la diminution de la vitesse processeur

[[Fichier:P32Montage.jpg|250px|thumb|left|'''Montage de test''']]
[[Fichier:P32resultats.jpg|250px|thumb|center|'''Visualisation du courant consommé lors d'envoi toutes les 10ms''']]

* On visualise à l'oscilloscope des pic d'envoi et des pic d'avertissement de la balise BLE, on peut ainsi déduire la puissance nécessaire de chaque action

===Semaine 6 (02/11/2015)===

* Test de diminution de la vitesse processeur

* Réalisation de graphique démontrant l'impact de la réduction de la vitesse processeur sur l'énergie consommée et déduction d'une vitesse optimale pour notre application

* Réunion du 4/11

Définition d'objectifs : Création d'un fichier excel permettant de caractériser les coûts en énergies de chaque étapes de fonctionnement du système.

* Création d'un environnement de test "normé" ( Pour éviter les variations de mesures on réalise un banc et on applique les mêmes conditions de test pour chaque essai)

* Recherche bibliographique sur la norme BLE : recherche du temps maximum entre deux "avertissements" de la balise BLE

===Semaine 7 (09/11/2015)===
* Explication du principe de communication BLE pour l'exploitation des résultats

[[Fichier:Freq.PNG]]

Nous nous intéressons dans notre projet à "l'observateur". Cet objet peut avoir trois états : stand-by, advertising et en communication.

[[Fichier:Brod2.png]]

Dans le mode "Advertising" le système peut :

- Avertir le système récepteur de la proximité d'un capteur

- Avertir de la présence à un appareil souhaitant ce connecter

- Ce reconnecter de façon asynchrone

===Semaine 8 (16/11/2015)===

Analyse en détail d'une trame BLE

[[Fichier:Com.PNG]]

On constate que pendant la durée de la trame il y a un échange entre les deux objets appairé. On s’intéresse ici uniquement aux actions "Slave Tx". Le but étant d'identifier la durée et le courant consommé par ces actions pour obtenir des valeurs en joules.

[[Fichier:SchemaCom.PNG]]

On constate donc deux phases :

- Advertising event

- Connexion event

Nous allons essayer de retrouver et quantifié l'énergie consommé dans ces deux phases.

===Semaine 9 (23/11/2015)===

Lors de cette semaine nous avons effectué des tests en respectant une procédure de test précise. En effet les valeurs des courants que nous relevons sont très petites aussi chaque variation du montage est susceptible de perturber les valeurs.

[[Fichier:P32Conne.jpg|250px|thumb|left|'''Phase connexion''']]

[[Fichier:Avertissement.jpg|250px|thumb|center|'''Phase Advertising''']]

===Semaine 10 (30/11/2015)===

- On cherche a diminuer légèrement la consommation par des modifications logiciel :

Réduction de la puissance de la radio BLE : Diminution de la portée

Augmentation de la fréquence d'advertising : tant que la fréquence d'advetising est inférieure a cette de relevé des capteurs on s'assure que la donnée envoyée est toujours mise à jour.

[[Fichier:Pwl20-envoi.jpg|250px|thumb|left|'''Avec modification logiciel''']]

[[Fichier:Sans-pwlvl.jpg|250px|thumb|center|'''Sans modification logiciel''']]

- On concentre nos résultats dans un tableau récapitulatif en vue du dimensionnement de la batterie du système

[[Fichier:P32tbresul.PNG]]

===Semaine 11 (07/12/2015)===

Tests d'intégration de plusieurs capteur et observations des modification de la consommation des ADC et de la durée/consommation de la transmission.

Réunion de vérification des tests.

Mise en évidence de la dualité consommation d'énergie - Temps de réponse du système

En effet chaque "Advertisement" consomme une quantité d'énergie nous pouvons gérer l'espacement entre ceux-ci mais plus ce temps serra élevé plus il faudra de temps pour ce connecter à ce périphérique.

* Rédaction d'un rapport de test

* Rédaction du rapport de pré soutenance

===Semaine 12 (14/12/2015)===
===Semaine 13 (04/01/2016)===

*Amélioration du modèle

L’amélioration du modèle est réalisée en tenant compte des facteurs influent sur la qualité de la transmission.
Ainsi grâce a un pico scope utilisé à l’IRCICA j’ai pu relever de nombreux échantillons nécessaire a une étude statistique des surcoûts en énergie.

===Semaine 14 (11/01/2016)===
===Semaine 15 (18/01/2016)===

Principe de fonctionnement du récupérateur d’énergie

Le récupérateur d’énergie fonctionne grâce à un patch piezo. Ce patch est capable de produire un courent à partir de la vélocité d’une impulsion suivent la formule :

[[Fichier:Equapiezo.PNG]]

[[Fichier:Modelepizo.PNG|250px|thumb|left|'''Modèle simplifié du patch piezo''']]

Pour récupérer de l’énergie il est couplé au système suivent :

[[Fichier:montagepiezo.PNG]]

La puissance du système est définie par :
P=V*im
L’énergie s’exprime alors :

E=V∫▒imdt
E=V*N∫▒〖w ̇dt〗
E=V*N* ∆w

L’énergie produite par le système est donc dépendante de la tension d’alimentation V de la constante électromécanique N et du choc produit sur le patch piezo.
Une impulsion sur le capteur piezo est de la forme :

La dérivée par rapport au temps de cette impulsion est donc de la forme :

Il est donc important de « fenêtrer » la tension pour ne récupérer que la partie positive.
Ce fenêtrage ainsi que la fréquence de commutation du hacheur est assurée par un microcontrôleur.

Dans la suite de notre étude nous ne tiendrons pas compte de la consommation de celui-ci.

===Semaine 16 (25/01/2016)===
===Semaine 17 (01/02/2016)===
===Semaine 18 (08/02/2016)===
===Semaine 19 (15/02/2016)===
===Semaine 20 (22/02/2016)===

== Annexes ==

Consommation du STM32L4 Series : http://www.st.com/web/en/catalog/mmc/FM141/SC1169/SS1580?sc=stm32l4

Réduction de la consommation de l'Arduino : http://www.home-automation-community.com/arduino-low-power-how-to-run-atmega328p-for-a-year-on-coin-cell-battery/

Consommation Raspberry : https://www.raspberrypi.org/help/faqs/

Module BLE : http://redbearlab.com/blemini/

Accéléromètre : http://fr.farnell.com/analog-devices/adxl345bccz/accelerometre-3-axes-14lga/dp/1853935

Capteur température : http://fr.farnell.com/analog-devices/tmp36gt9z/capteur-temp-to-92-3/dp/1438760?ost=TMP36GT9Z
ou http://fr.farnell.com/stmicroelectronics/stlm20w87f/capteur-de-temperature-analog/dp/1391131

Accéléromètre + Gyroscope : http://fr.farnell.com/invensense/mpu-6050/gyroscope-accelero-6-axes-i2c/dp/1864742

Altimètre : http://fr.farnell.com/freescale-semiconductor/mpl3115a2/pressure-sensor-20-110kpa-8lga/dp/2009084?ost=MPL3115A2&categoryId=700000004367

Explications norme BLE : chapters.comsoc.org/vancouver/BTLER3.pdf

http://www.argenox.com/bluetooth-low-energy-ble-v4-0-development/library/a-ble-advertising-primer/

== Rapport de Mi-projet ==

[[Fichier:CR_Miprojet_Sultana.pdf‎ ]]

Fichier:Equapiezo.PNG

2016-02-10T15:32:39Z

Qsultana : P32 : Équation piezo

P32 : Équation piezo

Fichier:Montagepiezo.PNG

2016-02-10T15:30:15Z

Qsultana : P32 : Montage piezo

P32 : Montage piezo

Fichier:Modelepizo.PNG

2016-02-10T15:26:00Z

Qsultana : P32 : Modèle du piezo

P32 : Modèle du piezo

P32 Récupération d'énergie pour balise BLE

2016-02-10T15:24:02Z

Qsultana : /* Semaine 15 (18/01/2016) */

== Objectif ==

Mon projet consiste à réaliser un système électronique autonome, composé de différents capteurs et capable de recueillir et de transmettre les données mémorisées vers un système centralisé.

== Etude préalable ==

L’énergie est le point de difficulté dans la réalisation de ce projet. Chaque élément devra être choisi non seulement pour ses performances mais également pour sa faible consommation.

== Organisation générale ==

Le système est organisé autour d’une source d’énergie, d’un contrôleur, de capteurs, de mémoire et d’un protocole de communication.

On cherche à minimiser l'énergie consommée par l'ensemble du système.

[[Fichier:P32Ensemble.PNG|250px|thumb|left|'''Architecture''']]

=== Chaine de l’énergie ===

L’énergie pour ce module autonome est constituée de quatre phases importantes :

[[Fichier:P32Energie.PNG]]

==== La récupération de l'énergie dans l'environnement ====

Il existe de nombreux moyens pour récupérer de l'énergie dans l'environnement. L'objectif est de trouver les sources les plus adaptées à l'environnement de l'application recherchée.

On peut citer:

* La récupération de l'énergie par différence de température

* Les panneaux photovoltaïques

* La récupération de l'énergie des ondes radio

* La Piézoélectricité

Dans ce projet nous utiliserons la piézoélectricité, le module de récupération ayant déjà fait partie d'une étude de IRCICA précédent le projet.

==== Le stockage de l’énergie ====

Le choix du système de stockage de l'énergie constitue une partie importante de la réalisation du système.
La problématique de cette partie sera de déterminer quel type de stockage nous utiliserons : batterie, super-capacité ou un hybride et de les dimensionner.
Il faudra tenir compte des problèmes de décharge partielle influent sur la durée de vie du stockage.

==== Le management/mise en forme de l’énergie ====

L'objectif de cette partie est d'étudier la nécessité de la mise en place d'une régulation tout en préservant des contraintes de consommation très faibles.

==== L'utilisation de l'énergie mise en forme ====

On cherche à minimiser l'énergie consommée par l'ensemble du système.

=== Contrôleur ===

Le microprocesseur : il existe différents types de microprocesseurs. L'objectif est de choisir un support capable de consommer un minimum d'énergie tout en conservant une taille minimale. Nous avons déjà utilisé dans d'autres projets des micro-contrôleurs de type Arduino et Raspberry pie. Ceux-ci ont pour avantage d’être prêts à l'emploi et faciles de prise en main. On peut s’orienter également vers un contrôleur ultra low power comme le STM32L4.

{| class="wikitable centre" width="80%"
|+
|-
! scope=col |
! scope=col | Consommation
! scope=col | Facilité de développement
! scope=col | Miniaturisation
|-
| width="33%" |
<center>Arduino</center>
| width="34%" |
<center>faible à très faible</center>
| width="33%" |
<center>bonne</center>
| width="33%" |
<center>faible</center>
|-
| width="33%" |
<center>Raspberry pi</center>
| width="34%" |
<center>importante</center>
| width="34%" |
<center>très bonne</center>
| width="34%" |
<center>très faible</center>
|-
| width="33%" |
<center>Ultra low power</center>
| width="34%" |
<center>très, très faible</center>
| width="33%" |
<center>difficile</center>
| width="33%" |
<center>forte</center>
|}

=== Capteurs ===

On peut imaginer différents types de capteurs :

* Accéléromètre

* Gyroscope

* Pression atmosphérique et altitude

* Température

* GPS

=== Mémoire ===

Le système doit être autonome et donc conserver un minimum de mesures pour les cas où la connexion est impossible. La mémoire doit être dimensionnée en fonction du nombre de capteurs, l’intervalle d’acquisition et le temps maximum avant connexion au système centralisé.

=== Protocole de communication ===

Un protocole de communication : dans un premier temps, nous nous concentrons sur le protocole BLE (Bluetooth Low Energie). Ce protocole étant standardisé, il nous permettra de recueillir de la documentation et réaliser des tests de consommation rapides.

== Planning prévisionnel ==

[[Fichier:P32Gant.PNG]]

==Suivi de l'avancement du Projet==
===Semaine 1 (28/09/2015)===

* Rencontre avec Monsieur Boe et Monsieur Giraud

* Présentation du projet

* Recherche documentaire

* Etablissement du cahier des charges

===Semaine 2 (05/10/2015)===

Recherche documentaire sur la consommation estimée des différents éléments.

{| class="wikitable centre" width="80%"
|+
|-
! scope=col | '''Contrôleur'''
! scope=col | Consommation Active
! scope=col | Consommation Inactive
! scope=col | Prix
|-
| width="33%" |
<center>Arduino Pro Mini 328 </center>
| width="34%" |
<center> 7mA (1 capteur)</center>
| width="33%" |
<center>4.5µA</center>
| width="33%" |
<center>Disponible</center>
|-
| width="33%" |
<center>STM32L4 Series (STM32L476JE)</center>
| width="34%" |
<center> 100 μA/MHz</center>
| width="33%" |
<center>120 nA</center>
| width="33%" |
<center>$5</center>
|-
| width="33%" |
<center>Raspberry</center>
| width="34%" |
<center> 200mA </center>
| width="33%" |
<center>200mA</center>
| width="33%" |
<center>Disponible</center>
|}

{| class="wikitable centre" width="80%"
|+
|-
! scope=col | '''Module BLE'''
! scope=col | Consommation
! scope=col | Options d'alimentation
! scope=col | Prix
|-
| width="33%" |
<center>BLE Mini</center>
| width="34%" |
<center> 15 mA </center>
| width="33%" |
<center>3.4V à 11V VIN / 5V USB / Coin Cell Battery (2025 or 2032) / 3.7V Li-ion Battery</center>
| width="33%" |
<center>$17</center>
|}

* <s> Le système Mini Arduino/ BLE Mini me semble être un bon compromis entre facilité d’intégration, consommation d'énergie et miniaturisation du système.</s> (Choix à discuter à la réunion du Merdredi 07/10)
* Choix du module RFduino

{| class="wikitable centre" width="80%"
|+
|-
! scope=col | '''Capteurs'''
! scope=col | Modèle
! scope=col | Alimentation min/max
! scope=col | Prix
|-
| width="33%" |
<center>Température</center>
| width="34%" |
<center> TMP36GT9Z </center>
| width="33%" |
<center>2.7V/5.5V</center>
| width="33%" |
<center>1,46 €</center>
|-
| width="33%" |
<center>Accéléromètre</center>
| width="34%" |
<center> ADXL345BCCZ </center>
| width="33%" |
<center>2V/3.6V</center>
| width="33%" |
<center>5,54 €</center>
|-
| width="33%" |
<center>Gyroscope+Accéléromètre</center>
| width="34%" |
<center> MPU-6050</center>
| width="33%" |
<center>2.5V/3.6V</center>
| width="33%" |
<center>15,73 €</center>
|-
| width="33%" |
<center>Pression atmosphérique / Altitude</center>
| width="34%" |
<center> MPL3115A2 </center>
| width="33%" |
<center>1.95V/3.6V</center>
| width="33%" |
<center>2,65 €</center>
|}

* Pour minimiser les pertes on cherche a travailler avec une tension d'alimentation la plus faible possible. Je propose de travailler avec une tension d'alimentation de 3,3V (Validé à discuter à la réunion du Merdredi 07/10)

* Le système de récupération d'énergie fonctionnant sur la base d'un mouvement, j'ai choisi l'ensemble des capteur ci dessus qui me semble être adapté à l'intégration dans un système en mouvement. (Validé à discuter à la réunion du Merdredi 07/10)

* Récupération des modules RFduino, prise en main

===Semaine 3 (12/10/2015)===

* Installation des librairies

* Visualisation d'exemples

* Tests d'implantation du code source du projet P14: Aimant intelligent de la session IMA4: 2014/2015

* Optimisation du code pour la réduction de la consommation d'énergie

* Recherches sur d'autres composants dans l'optique d'une consommation toujours plus faible

{| class="wikitable centre" width="80%"
|+
|-
! scope=col | '''Capteurs'''
! scope=col | Modèle
! scope=col | Alimentation min/max
! scope=col | Prix
! scope=col | Consommation (typ/max)
|-
| width="33%" |
<center>Température</center>
| width="34%" |
<center> STLM20W87F </center>
| width="33%" |
<center>2.4V/5.5V</center>
| width="33%" |
<center> 0,775 € </center>
| width="33%" |
<center> 4.8 μA/8.0 μA </center>
|}

'''Calcul théorique de la consommation énergétique du module BLE + RFD22301'''

Mode "endormi" : ARM CPU Running Current + Output standard drive current = 4 + 0.5 = 4.5mA

Mode "acquisition": ARM CPU Running Current + Output high drive current = 5 + 4 = 9mA

Mode "transmission" : ARM CPU Running Current + Transmit Current + Output standard drive current = 4 + 0.5 + 12 = 16.5mA

http://www.rfduino.com/wp-content/uploads/2014/03/RFD22301.Data_.Sheet_.11.24.13_11.38PM.pdf

'''Code possible du mode "endormi"'''

pinMode(5, INPUT);
RFduino_pinWake(5, HIGH);

RFduino_ULPDelay(INFINITE);
if (RFduino_pinWoke(5))
{
state = ! state;
RFduinoGZLL.sendToHost(state);
}

http://forum.rfduino.com/index.php?topic=385.0

===Semaine 4 (19/10/2015)===

* Réunion du 21/10

* Réalisation de tests

* Ajustement du nombre de capteurs : dans un premier temps on utilisera le capteur de température puis l'accéléromètre

* Discussion sur le bac de test et méthodes de test : résistance de visualisation, chronométrage du temps de transmission, vitesse du processeur

* Réalisation des premiers relevés

===Semaine 5 (26/10/2015)===

* Recherche bibliographique sur les modes d'endormissement du module RFduino

* Essais de codes utilisant un mode d'endormissement plus profond

* Réalisation de graphique de l'énergie utilisée par le module lors de la transmission d'un message par le module BLE.

* Recherches sur des méthodes de programmation pour la diminution de la vitesse processeur

[[Fichier:P32Montage.jpg|250px|thumb|left|'''Montage de test''']]
[[Fichier:P32resultats.jpg|250px|thumb|center|'''Visualisation du courant consommé lors d'envoi toutes les 10ms''']]

* On visualise à l'oscilloscope des pic d'envoi et des pic d'avertissement de la balise BLE, on peut ainsi déduire la puissance nécessaire de chaque action

===Semaine 6 (02/11/2015)===

* Test de diminution de la vitesse processeur

* Réalisation de graphique démontrant l'impact de la réduction de la vitesse processeur sur l'énergie consommée et déduction d'une vitesse optimale pour notre application

* Réunion du 4/11

Définition d'objectifs : Création d'un fichier excel permettant de caractériser les coûts en énergies de chaque étapes de fonctionnement du système.

* Création d'un environnement de test "normé" ( Pour éviter les variations de mesures on réalise un banc et on applique les mêmes conditions de test pour chaque essai)

* Recherche bibliographique sur la norme BLE : recherche du temps maximum entre deux "avertissements" de la balise BLE

===Semaine 7 (09/11/2015)===
* Explication du principe de communication BLE pour l'exploitation des résultats

[[Fichier:Freq.PNG]]

Nous nous intéressons dans notre projet à "l'observateur". Cet objet peut avoir trois états : stand-by, advertising et en communication.

[[Fichier:Brod2.png]]

Dans le mode "Advertising" le système peut :

- Avertir le système récepteur de la proximité d'un capteur

- Avertir de la présence à un appareil souhaitant ce connecter

- Ce reconnecter de façon asynchrone

===Semaine 8 (16/11/2015)===

Analyse en détail d'une trame BLE

[[Fichier:Com.PNG]]

On constate que pendant la durée de la trame il y a un échange entre les deux objets appairé. On s’intéresse ici uniquement aux actions "Slave Tx". Le but étant d'identifier la durée et le courant consommé par ces actions pour obtenir des valeurs en joules.

[[Fichier:SchemaCom.PNG]]

On constate donc deux phases :

- Advertising event

- Connexion event

Nous allons essayer de retrouver et quantifié l'énergie consommé dans ces deux phases.

===Semaine 9 (23/11/2015)===

Lors de cette semaine nous avons effectué des tests en respectant une procédure de test précise. En effet les valeurs des courants que nous relevons sont très petites aussi chaque variation du montage est susceptible de perturber les valeurs.

[[Fichier:P32Conne.jpg|250px|thumb|left|'''Phase connexion''']]

[[Fichier:Avertissement.jpg|250px|thumb|center|'''Phase Advertising''']]

===Semaine 10 (30/11/2015)===

- On cherche a diminuer légèrement la consommation par des modifications logiciel :

Réduction de la puissance de la radio BLE : Diminution de la portée

Augmentation de la fréquence d'advertising : tant que la fréquence d'advetising est inférieure a cette de relevé des capteurs on s'assure que la donnée envoyée est toujours mise à jour.

[[Fichier:Pwl20-envoi.jpg|250px|thumb|left|'''Avec modification logiciel''']]

[[Fichier:Sans-pwlvl.jpg|250px|thumb|center|'''Sans modification logiciel''']]

- On concentre nos résultats dans un tableau récapitulatif en vue du dimensionnement de la batterie du système

[[Fichier:P32tbresul.PNG]]

===Semaine 11 (07/12/2015)===

Tests d'intégration de plusieurs capteur et observations des modification de la consommation des ADC et de la durée/consommation de la transmission.

Réunion de vérification des tests.

Mise en évidence de la dualité consommation d'énergie - Temps de réponse du système

En effet chaque "Advertisement" consomme une quantité d'énergie nous pouvons gérer l'espacement entre ceux-ci mais plus ce temps serra élevé plus il faudra de temps pour ce connecter à ce périphérique.

* Rédaction d'un rapport de test

* Rédaction du rapport de pré soutenance

===Semaine 12 (14/12/2015)===
===Semaine 13 (04/01/2016)===

*Amélioration du modèle

L’amélioration du modèle est réalisée en tenant compte des facteurs influent sur la qualité de la transmission.
Ainsi grâce a un pico scope utilisé à l’IRCICA j’ai pu relever de nombreux échantillons nécessaire a une étude statistique des surcoûts en énergie.

===Semaine 14 (11/01/2016)===
===Semaine 15 (18/01/2016)===

Principe de fonctionnement du récupérateur d’énergie

Le récupérateur d’énergie fonctionne grâce à un patch piezo. Ce patch est capable de produire un courent à partir de la vélocité d’une impulsion suivent la formule :

im = N * w ̇

Pour récupérer de l’énergie il est couplé au système suivent :

La puissance du système est définie par :
P=V*im
L’énergie s’exprime alors :

E=V∫▒imdt
E=V*N∫▒〖w ̇dt〗
E=V*N* ∆w

L’énergie produite par le système est donc dépendante de la tension d’alimentation V de la constante électromécanique N et du choc produit sur le patch piezo.
Une impulsion sur le capteur piezo est de la forme :

La dérivée par rapport au temps de cette impulsion est donc de la forme :

Il est donc important de « fenêtrer » la tension pour ne récupérer que la partie positive.
Ce fenêtrage ainsi que la fréquence de commutation du hacheur est assurée par un microcontrôleur.

Dans la suite de notre étude nous ne tiendrons pas compte de la consommation de celui-ci.

===Semaine 16 (25/01/2016)===
===Semaine 17 (01/02/2016)===
===Semaine 18 (08/02/2016)===
===Semaine 19 (15/02/2016)===
===Semaine 20 (22/02/2016)===

== Annexes ==

Consommation du STM32L4 Series : http://www.st.com/web/en/catalog/mmc/FM141/SC1169/SS1580?sc=stm32l4

Réduction de la consommation de l'Arduino : http://www.home-automation-community.com/arduino-low-power-how-to-run-atmega328p-for-a-year-on-coin-cell-battery/

Consommation Raspberry : https://www.raspberrypi.org/help/faqs/

Module BLE : http://redbearlab.com/blemini/

Accéléromètre : http://fr.farnell.com/analog-devices/adxl345bccz/accelerometre-3-axes-14lga/dp/1853935

Capteur température : http://fr.farnell.com/analog-devices/tmp36gt9z/capteur-temp-to-92-3/dp/1438760?ost=TMP36GT9Z
ou http://fr.farnell.com/stmicroelectronics/stlm20w87f/capteur-de-temperature-analog/dp/1391131

Accéléromètre + Gyroscope : http://fr.farnell.com/invensense/mpu-6050/gyroscope-accelero-6-axes-i2c/dp/1864742

Altimètre : http://fr.farnell.com/freescale-semiconductor/mpl3115a2/pressure-sensor-20-110kpa-8lga/dp/2009084?ost=MPL3115A2&categoryId=700000004367

Explications norme BLE : chapters.comsoc.org/vancouver/BTLER3.pdf

http://www.argenox.com/bluetooth-low-energy-ble-v4-0-development/library/a-ble-advertising-primer/

== Rapport de Mi-projet ==

[[Fichier:CR_Miprojet_Sultana.pdf‎ ]]

P32 Récupération d'énergie pour balise BLE

2016-02-10T15:19:31Z

Qsultana : /* Semaine 13 (04/01/2016) */

== Objectif ==

Mon projet consiste à réaliser un système électronique autonome, composé de différents capteurs et capable de recueillir et de transmettre les données mémorisées vers un système centralisé.

== Etude préalable ==

L’énergie est le point de difficulté dans la réalisation de ce projet. Chaque élément devra être choisi non seulement pour ses performances mais également pour sa faible consommation.

== Organisation générale ==

Le système est organisé autour d’une source d’énergie, d’un contrôleur, de capteurs, de mémoire et d’un protocole de communication.

On cherche à minimiser l'énergie consommée par l'ensemble du système.

[[Fichier:P32Ensemble.PNG|250px|thumb|left|'''Architecture''']]

=== Chaine de l’énergie ===

L’énergie pour ce module autonome est constituée de quatre phases importantes :

[[Fichier:P32Energie.PNG]]

==== La récupération de l'énergie dans l'environnement ====

Il existe de nombreux moyens pour récupérer de l'énergie dans l'environnement. L'objectif est de trouver les sources les plus adaptées à l'environnement de l'application recherchée.

On peut citer:

* La récupération de l'énergie par différence de température

* Les panneaux photovoltaïques

* La récupération de l'énergie des ondes radio

* La Piézoélectricité

Dans ce projet nous utiliserons la piézoélectricité, le module de récupération ayant déjà fait partie d'une étude de IRCICA précédent le projet.

==== Le stockage de l’énergie ====

Le choix du système de stockage de l'énergie constitue une partie importante de la réalisation du système.
La problématique de cette partie sera de déterminer quel type de stockage nous utiliserons : batterie, super-capacité ou un hybride et de les dimensionner.
Il faudra tenir compte des problèmes de décharge partielle influent sur la durée de vie du stockage.

==== Le management/mise en forme de l’énergie ====

L'objectif de cette partie est d'étudier la nécessité de la mise en place d'une régulation tout en préservant des contraintes de consommation très faibles.

==== L'utilisation de l'énergie mise en forme ====

On cherche à minimiser l'énergie consommée par l'ensemble du système.

=== Contrôleur ===

Le microprocesseur : il existe différents types de microprocesseurs. L'objectif est de choisir un support capable de consommer un minimum d'énergie tout en conservant une taille minimale. Nous avons déjà utilisé dans d'autres projets des micro-contrôleurs de type Arduino et Raspberry pie. Ceux-ci ont pour avantage d’être prêts à l'emploi et faciles de prise en main. On peut s’orienter également vers un contrôleur ultra low power comme le STM32L4.

{| class="wikitable centre" width="80%"
|+
|-
! scope=col |
! scope=col | Consommation
! scope=col | Facilité de développement
! scope=col | Miniaturisation
|-
| width="33%" |
<center>Arduino</center>
| width="34%" |
<center>faible à très faible</center>
| width="33%" |
<center>bonne</center>
| width="33%" |
<center>faible</center>
|-
| width="33%" |
<center>Raspberry pi</center>
| width="34%" |
<center>importante</center>
| width="34%" |
<center>très bonne</center>
| width="34%" |
<center>très faible</center>
|-
| width="33%" |
<center>Ultra low power</center>
| width="34%" |
<center>très, très faible</center>
| width="33%" |
<center>difficile</center>
| width="33%" |
<center>forte</center>
|}

=== Capteurs ===

On peut imaginer différents types de capteurs :

* Accéléromètre

* Gyroscope

* Pression atmosphérique et altitude

* Température

* GPS

=== Mémoire ===

Le système doit être autonome et donc conserver un minimum de mesures pour les cas où la connexion est impossible. La mémoire doit être dimensionnée en fonction du nombre de capteurs, l’intervalle d’acquisition et le temps maximum avant connexion au système centralisé.

=== Protocole de communication ===

Un protocole de communication : dans un premier temps, nous nous concentrons sur le protocole BLE (Bluetooth Low Energie). Ce protocole étant standardisé, il nous permettra de recueillir de la documentation et réaliser des tests de consommation rapides.

== Planning prévisionnel ==

[[Fichier:P32Gant.PNG]]

==Suivi de l'avancement du Projet==
===Semaine 1 (28/09/2015)===

* Rencontre avec Monsieur Boe et Monsieur Giraud

* Présentation du projet

* Recherche documentaire

* Etablissement du cahier des charges

===Semaine 2 (05/10/2015)===

Recherche documentaire sur la consommation estimée des différents éléments.

{| class="wikitable centre" width="80%"
|+
|-
! scope=col | '''Contrôleur'''
! scope=col | Consommation Active
! scope=col | Consommation Inactive
! scope=col | Prix
|-
| width="33%" |
<center>Arduino Pro Mini 328 </center>
| width="34%" |
<center> 7mA (1 capteur)</center>
| width="33%" |
<center>4.5µA</center>
| width="33%" |
<center>Disponible</center>
|-
| width="33%" |
<center>STM32L4 Series (STM32L476JE)</center>
| width="34%" |
<center> 100 μA/MHz</center>
| width="33%" |
<center>120 nA</center>
| width="33%" |
<center>$5</center>
|-
| width="33%" |
<center>Raspberry</center>
| width="34%" |
<center> 200mA </center>
| width="33%" |
<center>200mA</center>
| width="33%" |
<center>Disponible</center>
|}

{| class="wikitable centre" width="80%"
|+
|-
! scope=col | '''Module BLE'''
! scope=col | Consommation
! scope=col | Options d'alimentation
! scope=col | Prix
|-
| width="33%" |
<center>BLE Mini</center>
| width="34%" |
<center> 15 mA </center>
| width="33%" |
<center>3.4V à 11V VIN / 5V USB / Coin Cell Battery (2025 or 2032) / 3.7V Li-ion Battery</center>
| width="33%" |
<center>$17</center>
|}

* <s> Le système Mini Arduino/ BLE Mini me semble être un bon compromis entre facilité d’intégration, consommation d'énergie et miniaturisation du système.</s> (Choix à discuter à la réunion du Merdredi 07/10)
* Choix du module RFduino

{| class="wikitable centre" width="80%"
|+
|-
! scope=col | '''Capteurs'''
! scope=col | Modèle
! scope=col | Alimentation min/max
! scope=col | Prix
|-
| width="33%" |
<center>Température</center>
| width="34%" |
<center> TMP36GT9Z </center>
| width="33%" |
<center>2.7V/5.5V</center>
| width="33%" |
<center>1,46 €</center>
|-
| width="33%" |
<center>Accéléromètre</center>
| width="34%" |
<center> ADXL345BCCZ </center>
| width="33%" |
<center>2V/3.6V</center>
| width="33%" |
<center>5,54 €</center>
|-
| width="33%" |
<center>Gyroscope+Accéléromètre</center>
| width="34%" |
<center> MPU-6050</center>
| width="33%" |
<center>2.5V/3.6V</center>
| width="33%" |
<center>15,73 €</center>
|-
| width="33%" |
<center>Pression atmosphérique / Altitude</center>
| width="34%" |
<center> MPL3115A2 </center>
| width="33%" |
<center>1.95V/3.6V</center>
| width="33%" |
<center>2,65 €</center>
|}

* Pour minimiser les pertes on cherche a travailler avec une tension d'alimentation la plus faible possible. Je propose de travailler avec une tension d'alimentation de 3,3V (Validé à discuter à la réunion du Merdredi 07/10)

* Le système de récupération d'énergie fonctionnant sur la base d'un mouvement, j'ai choisi l'ensemble des capteur ci dessus qui me semble être adapté à l'intégration dans un système en mouvement. (Validé à discuter à la réunion du Merdredi 07/10)

* Récupération des modules RFduino, prise en main

===Semaine 3 (12/10/2015)===

* Installation des librairies

* Visualisation d'exemples

* Tests d'implantation du code source du projet P14: Aimant intelligent de la session IMA4: 2014/2015

* Optimisation du code pour la réduction de la consommation d'énergie

* Recherches sur d'autres composants dans l'optique d'une consommation toujours plus faible

{| class="wikitable centre" width="80%"
|+
|-
! scope=col | '''Capteurs'''
! scope=col | Modèle
! scope=col | Alimentation min/max
! scope=col | Prix
! scope=col | Consommation (typ/max)
|-
| width="33%" |
<center>Température</center>
| width="34%" |
<center> STLM20W87F </center>
| width="33%" |
<center>2.4V/5.5V</center>
| width="33%" |
<center> 0,775 € </center>
| width="33%" |
<center> 4.8 μA/8.0 μA </center>
|}

'''Calcul théorique de la consommation énergétique du module BLE + RFD22301'''

Mode "endormi" : ARM CPU Running Current + Output standard drive current = 4 + 0.5 = 4.5mA

Mode "acquisition": ARM CPU Running Current + Output high drive current = 5 + 4 = 9mA

Mode "transmission" : ARM CPU Running Current + Transmit Current + Output standard drive current = 4 + 0.5 + 12 = 16.5mA

http://www.rfduino.com/wp-content/uploads/2014/03/RFD22301.Data_.Sheet_.11.24.13_11.38PM.pdf

'''Code possible du mode "endormi"'''

pinMode(5, INPUT);
RFduino_pinWake(5, HIGH);

RFduino_ULPDelay(INFINITE);
if (RFduino_pinWoke(5))
{
state = ! state;
RFduinoGZLL.sendToHost(state);
}

http://forum.rfduino.com/index.php?topic=385.0

===Semaine 4 (19/10/2015)===

* Réunion du 21/10

* Réalisation de tests

* Ajustement du nombre de capteurs : dans un premier temps on utilisera le capteur de température puis l'accéléromètre

* Discussion sur le bac de test et méthodes de test : résistance de visualisation, chronométrage du temps de transmission, vitesse du processeur

* Réalisation des premiers relevés

===Semaine 5 (26/10/2015)===

* Recherche bibliographique sur les modes d'endormissement du module RFduino

* Essais de codes utilisant un mode d'endormissement plus profond

* Réalisation de graphique de l'énergie utilisée par le module lors de la transmission d'un message par le module BLE.

* Recherches sur des méthodes de programmation pour la diminution de la vitesse processeur

[[Fichier:P32Montage.jpg|250px|thumb|left|'''Montage de test''']]
[[Fichier:P32resultats.jpg|250px|thumb|center|'''Visualisation du courant consommé lors d'envoi toutes les 10ms''']]

* On visualise à l'oscilloscope des pic d'envoi et des pic d'avertissement de la balise BLE, on peut ainsi déduire la puissance nécessaire de chaque action

===Semaine 6 (02/11/2015)===

* Test de diminution de la vitesse processeur

* Réalisation de graphique démontrant l'impact de la réduction de la vitesse processeur sur l'énergie consommée et déduction d'une vitesse optimale pour notre application

* Réunion du 4/11

Définition d'objectifs : Création d'un fichier excel permettant de caractériser les coûts en énergies de chaque étapes de fonctionnement du système.

* Création d'un environnement de test "normé" ( Pour éviter les variations de mesures on réalise un banc et on applique les mêmes conditions de test pour chaque essai)

* Recherche bibliographique sur la norme BLE : recherche du temps maximum entre deux "avertissements" de la balise BLE

===Semaine 7 (09/11/2015)===
* Explication du principe de communication BLE pour l'exploitation des résultats

[[Fichier:Freq.PNG]]

Nous nous intéressons dans notre projet à "l'observateur". Cet objet peut avoir trois états : stand-by, advertising et en communication.

[[Fichier:Brod2.png]]

Dans le mode "Advertising" le système peut :

- Avertir le système récepteur de la proximité d'un capteur

- Avertir de la présence à un appareil souhaitant ce connecter

- Ce reconnecter de façon asynchrone

===Semaine 8 (16/11/2015)===

Analyse en détail d'une trame BLE

[[Fichier:Com.PNG]]

On constate que pendant la durée de la trame il y a un échange entre les deux objets appairé. On s’intéresse ici uniquement aux actions "Slave Tx". Le but étant d'identifier la durée et le courant consommé par ces actions pour obtenir des valeurs en joules.

[[Fichier:SchemaCom.PNG]]

On constate donc deux phases :

- Advertising event

- Connexion event

Nous allons essayer de retrouver et quantifié l'énergie consommé dans ces deux phases.

===Semaine 9 (23/11/2015)===

Lors de cette semaine nous avons effectué des tests en respectant une procédure de test précise. En effet les valeurs des courants que nous relevons sont très petites aussi chaque variation du montage est susceptible de perturber les valeurs.

[[Fichier:P32Conne.jpg|250px|thumb|left|'''Phase connexion''']]

[[Fichier:Avertissement.jpg|250px|thumb|center|'''Phase Advertising''']]

===Semaine 10 (30/11/2015)===

- On cherche a diminuer légèrement la consommation par des modifications logiciel :

Réduction de la puissance de la radio BLE : Diminution de la portée

Augmentation de la fréquence d'advertising : tant que la fréquence d'advetising est inférieure a cette de relevé des capteurs on s'assure que la donnée envoyée est toujours mise à jour.

[[Fichier:Pwl20-envoi.jpg|250px|thumb|left|'''Avec modification logiciel''']]

[[Fichier:Sans-pwlvl.jpg|250px|thumb|center|'''Sans modification logiciel''']]

- On concentre nos résultats dans un tableau récapitulatif en vue du dimensionnement de la batterie du système

[[Fichier:P32tbresul.PNG]]

===Semaine 11 (07/12/2015)===

Tests d'intégration de plusieurs capteur et observations des modification de la consommation des ADC et de la durée/consommation de la transmission.

Réunion de vérification des tests.

Mise en évidence de la dualité consommation d'énergie - Temps de réponse du système

En effet chaque "Advertisement" consomme une quantité d'énergie nous pouvons gérer l'espacement entre ceux-ci mais plus ce temps serra élevé plus il faudra de temps pour ce connecter à ce périphérique.

* Rédaction d'un rapport de test

* Rédaction du rapport de pré soutenance

===Semaine 12 (14/12/2015)===
===Semaine 13 (04/01/2016)===

*Amélioration du modèle

L’amélioration du modèle est réalisée en tenant compte des facteurs influent sur la qualité de la transmission.
Ainsi grâce a un pico scope utilisé à l’IRCICA j’ai pu relever de nombreux échantillons nécessaire a une étude statistique des surcoûts en énergie.

===Semaine 14 (11/01/2016)===
===Semaine 15 (18/01/2016)===
===Semaine 16 (25/01/2016)===
===Semaine 17 (01/02/2016)===
===Semaine 18 (08/02/2016)===
===Semaine 19 (15/02/2016)===
===Semaine 20 (22/02/2016)===

== Annexes ==

Consommation du STM32L4 Series : http://www.st.com/web/en/catalog/mmc/FM141/SC1169/SS1580?sc=stm32l4

Réduction de la consommation de l'Arduino : http://www.home-automation-community.com/arduino-low-power-how-to-run-atmega328p-for-a-year-on-coin-cell-battery/

Consommation Raspberry : https://www.raspberrypi.org/help/faqs/

Module BLE : http://redbearlab.com/blemini/

Accéléromètre : http://fr.farnell.com/analog-devices/adxl345bccz/accelerometre-3-axes-14lga/dp/1853935

Capteur température : http://fr.farnell.com/analog-devices/tmp36gt9z/capteur-temp-to-92-3/dp/1438760?ost=TMP36GT9Z
ou http://fr.farnell.com/stmicroelectronics/stlm20w87f/capteur-de-temperature-analog/dp/1391131

Accéléromètre + Gyroscope : http://fr.farnell.com/invensense/mpu-6050/gyroscope-accelero-6-axes-i2c/dp/1864742

Altimètre : http://fr.farnell.com/freescale-semiconductor/mpl3115a2/pressure-sensor-20-110kpa-8lga/dp/2009084?ost=MPL3115A2&categoryId=700000004367

Explications norme BLE : chapters.comsoc.org/vancouver/BTLER3.pdf

http://www.argenox.com/bluetooth-low-energy-ble-v4-0-development/library/a-ble-advertising-primer/

== Rapport de Mi-projet ==

[[Fichier:CR_Miprojet_Sultana.pdf‎ ]]

Projets IMA5 2015/2016

2015-12-15T13:28:04Z

Qsultana : /* Répartition des binômes */

Merci de référencer vos pages de projets ici. Merci aussi d'uniformiser vos formats que ce soit en regardant la présentation des projets déjà créés ou en allant modifier le format des précédents si votre façon de faire vous semble la meilleure. Dans tous les cas un minimum de communication entre les binômes est conseillée.

Toutes les sources doivent être déposées sur notre archive GIT. Le service est disponible à l'URL [https://archives.plil.fr archives.plil.fr]. Connectez-vous avec vos identifiants Polytech'Lille. Sauf indication contraire de vos encadrants, rendez le projet public et mettez le lien sur votre Wiki. Vous pouvez trouver de la documentation sur ce système d'archives sur ce [https://git-scm.com/book/fr/v1 site].

== Répartition des binômes ==

<table border="1">
<tr>
<th>Projet</th>
<th>Elèves</th>
<th>Encadrant Ecole</th>
<th>Rapport décembre</th>
<th>Rapports finaux</th>
<th>Vidéo</th>
</tr>
<tr>
<td>[[P1 Convertisseur DC/DC pour réseau MTDC]]</td>
<td> Mehmet Ilter </td>
<td> Philippe DELARUE </td>
<td> </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P2 Data Logger]]</td>
<td> Hidéo VINOT</td>
<td> Alexandre Boé / Thomas Vantroys </td>
<td> 15/12/2015 12;00</td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P4 Jukebox multi-pièces]]</td>
<td> Alexandre Jouy / Julien hérin </td>
<td> Rodolphe Astori / Xavier Redon / Alexandre Boé / Thomas Vantroys </td>
<td> [[Fichier:Pre_soutenance_PFE_Jouy_herin.pdf]] </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P9 Système d'hébergement domestique]]</td>
<td> Romain Libaert / Timothée Teneur </td>
<td> Xavier Redon / Alexandre Boé / Thomas Vantroys </td>
<td> 15/12/2015, 10:21, [[Fichier:P9_LIBAERT_TENEUR_DEC15.pdf]]</td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P10 LILLIAD: Connected Learning Center | P10 LILLIAD: learning center connecté]]</td>
<td> Mageshwaran Sekar </td>
<td> Alexandre Boé / Thomas Vantroys </td>
<td> 15/12/2015,07:48, [[Fichier:P10_FYP_December_Report_M_SEKAR.pdf]]</td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P11 Spectateur augmenté]]</td>
<td> Teresa Tumbragel </td>
<td> Alexandre Boé / Thomas Vantroys </td>
<td> </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P12 Capteurs enfouis pour vieillissement du béton]]</td>
<td> JULITA Alex </td>
<td> Alexandre Boé / Thomas Vantroys </td>
<td> </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P14 Localisation dans le corps humain]]</td>
<td> Matthieu Marcadet </td>
<td> Alexandre Boé / Thomas Vantroys </td>
<td> 15/12/2015, 10:52, [[Fichier:Rapport_intermediaire_PFE_Marcadet.pdf]]</td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P18 Meuble intelligent]]</td>
<td> Kevin Colautti / Benjamin Lefort </td>
<td> Rémy Bernard / Alexandre Boé / Xavier Redon / Thomas Vantroys </td>
<td> 14/12/2015, 14:44, [[Fichier:P18_pre_soutenance.pdf]]</td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[Automatic Soldering System Project|P20 Placeur de composants sur PCB]]</td>
<td> Jean Wasilewski & Pierre Letousey </td>
<td> Xavier Redon / Thomas Vantroys / Alexandre Boé </td>
<td> [[Fichier:P20_ASSP.pdf]]</td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P24 Nuage pour sites Web]]</td>
<td> Jeremie Denechaud / Thibaut Scholaert </td>
<td> Xavier Redon / Thomas Vantroys </td>
<td> 15/12/2015, 12:02, [[Fichier:P24_Denechaud_Scholaert.pdf| Rapport intermédiaire de projet]]</td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P25 Architecture ROS pour des véhicules autonomes intelligents]]</td>
<td> Jean-Michel Tournier / Cyril Smagghe </td>
<td> Vincent Coelen et Rochdi Merzouki </td>
<td> 15/12/2015,09:04, [[Fichier:P25-2015_Smagghe_Tournier_decembre.pdf]]</td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P26 Robot de forgeage et d’usinage]]</td>
<td> Bertrand Yvernault / Louis Thebault </td>
<td> Rochdi Merzouki </td>
<td> 14/12/2015, 17:51</td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P27 Robot de fraiseuse]]</td>
<td> Flavien Royer / Maxime Morisse </td>
<td> Rochdi Merzouki </td>
<td> 14/12/2015, 19:06, [[Fichier:Rapport_Royer_Morisse.pdf]]</td>
<td> </td>
<td> </td>
</tr>

<tr>
<td>[[P30 Thermostat connecté et intelligent]]</td>
<td> TISSOT Elise / TIRABY Céline </td>
<td> Guillaume Renault / Alexandre Boé / Xavier Redon </td>
<td>15/12/2015, 00:35, [[Fichier:Rapport_PFE_TISSOT_TIRABY.pdf‎ ]] </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P32 Récupération d'énergie pour balise BLE]]</td>
<td> Quentin Sultana </td>
<td> Frédéric Giraud / Alexandre Boé / Thomas Vantroys </td>
<td> 13/12/2015, 19:31, [[Fichier:CR Miprojet_Sultana.pdf]]</td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P33 Réalisations en faveur de l'accessibilité de jeux vidéos]]</td>
<td> Jérôme Bailet / Mehdi Zeggaï </td>
<td> GAPAS / Laurent Grisoni / Thomas Vantroys </td>
<td> 14/12/2015, 10:54, [[Fichier:PFE_IMA5_Rapport_intermediaire_Bailet_Zeggai.pdf]]</td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P35 Robot de test pour le sport de Golf]]</td>
<td> Deborah Saunders </td>
<td> Rochdi Merzouki </td>
<td> 15/12/2015, 12:07</td>
<td> </td>
<td> </td>
</tr>

<tr>
<td>[[P34 Optimisation de trajectoire pour un robot de curiethérapie]]</td>
<td> Sandra HAGE CHEHADE / Thomas DANEL </td>
<td> Vincent COELEN / Rochdi MERZOUKI </td>
<td> 15/12/2015, 12:02</td>
<td> </td>
<td> </td>
</tr>

<tr>
<td>[[P40 Maquette mécatronique durcie d'ascenseur 5 étages]]</td>
<td> Louis CHAUCHARD / Romain IMBERT </td>
<td> Blaise CONRARD </td>
<td> 14/12/2015, 19:21</td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P13 Plateforme expérimentation IOT]]</td>
<td> ROCHE François </td>
<td> Alexandre Boé / Thomas Vantroys </td>
<td> 14/12/2015, 19:37, [[Fichier:PFE_P13_Plateforme_expérimentation_IOT.pdf]] </td>
<td> </td>
<td> </td>
</tr>
</table>

P32 Récupération d'énergie pour balise BLE

2015-12-13T18:28:18Z

Qsultana : /* Rapport de Mi-projet */

== Objectif ==

Mon projet consiste à réaliser un système électronique autonome, composé de différents capteurs et capable de recueillir et de transmettre les données mémorisées vers un système centralisé.

== Etude préalable ==

L’énergie est le point de difficulté dans la réalisation de ce projet. Chaque élément devra être choisi non seulement pour ses performances mais également pour sa faible consommation.

== Organisation générale ==

Le système est organisé autour d’une source d’énergie, d’un contrôleur, de capteurs, de mémoire et d’un protocole de communication.

On cherche à minimiser l'énergie consommée par l'ensemble du système.

[[Fichier:P32Ensemble.PNG|250px|thumb|left|'''Architecture''']]

=== Chaine de l’énergie ===

L’énergie pour ce module autonome est constituée de quatre phases importantes :

[[Fichier:P32Energie.PNG]]

==== La récupération de l'énergie dans l'environnement ====

Il existe de nombreux moyens pour récupérer de l'énergie dans l'environnement. L'objectif est de trouver les sources les plus adaptées à l'environnement de l'application recherchée.

On peut citer:

* La récupération de l'énergie par différence de température

* Les panneaux photovoltaïques

* La récupération de l'énergie des ondes radio

* La Piézoélectricité

Dans ce projet nous utiliserons la piézoélectricité, le module de récupération ayant déjà fait partie d'une étude de IRCICA précédent le projet.

==== Le stockage de l’énergie ====

Le choix du système de stockage de l'énergie constitue une partie importante de la réalisation du système.
La problématique de cette partie sera de déterminer quel type de stockage nous utiliserons : batterie, super-capacité ou un hybride et de les dimensionner.
Il faudra tenir compte des problèmes de décharge partielle influent sur la durée de vie du stockage.

==== Le management/mise en forme de l’énergie ====

L'objectif de cette partie est d'étudier la nécessité de la mise en place d'une régulation tout en préservant des contraintes de consommation très faibles.

==== L'utilisation de l'énergie mise en forme ====

On cherche à minimiser l'énergie consommée par l'ensemble du système.

=== Contrôleur ===

Le microprocesseur : il existe différents types de microprocesseurs. L'objectif est de choisir un support capable de consommer un minimum d'énergie tout en conservant une taille minimale. Nous avons déjà utilisé dans d'autres projets des micro-contrôleurs de type Arduino et Raspberry pie. Ceux-ci ont pour avantage d’être prêts à l'emploi et faciles de prise en main. On peut s’orienter également vers un contrôleur ultra low power comme le STM32L4.

{| class="wikitable centre" width="80%"
|+
|-
! scope=col |
! scope=col | Consommation
! scope=col | Facilité de développement
! scope=col | Miniaturisation
|-
| width="33%" |
<center>Arduino</center>
| width="34%" |
<center>faible à très faible</center>
| width="33%" |
<center>bonne</center>
| width="33%" |
<center>faible</center>
|-
| width="33%" |
<center>Raspberry pi</center>
| width="34%" |
<center>importante</center>
| width="34%" |
<center>très bonne</center>
| width="34%" |
<center>très faible</center>
|-
| width="33%" |
<center>Ultra low power</center>
| width="34%" |
<center>très, très faible</center>
| width="33%" |
<center>difficile</center>
| width="33%" |
<center>forte</center>
|}

=== Capteurs ===

On peut imaginer différents types de capteurs :

* Accéléromètre

* Gyroscope

* Pression atmosphérique et altitude

* Température

* GPS

=== Mémoire ===

Le système doit être autonome et donc conserver un minimum de mesures pour les cas où la connexion est impossible. La mémoire doit être dimensionnée en fonction du nombre de capteurs, l’intervalle d’acquisition et le temps maximum avant connexion au système centralisé.

=== Protocole de communication ===

Un protocole de communication : dans un premier temps, nous nous concentrons sur le protocole BLE (Bluetooth Low Energie). Ce protocole étant standardisé, il nous permettra de recueillir de la documentation et réaliser des tests de consommation rapides.

== Planning prévisionnel ==

[[Fichier:P32Gant.PNG]]

==Suivi de l'avancement du Projet==
===Semaine 1 (28/09/2015)===

* Rencontre avec Monsieur Boe et Monsieur Giraud

* Présentation du projet

* Recherche documentaire

* Etablissement du cahier des charges

===Semaine 2 (05/10/2015)===

Recherche documentaire sur la consommation estimée des différents éléments.

{| class="wikitable centre" width="80%"
|+
|-
! scope=col | '''Contrôleur'''
! scope=col | Consommation Active
! scope=col | Consommation Inactive
! scope=col | Prix
|-
| width="33%" |
<center>Arduino Pro Mini 328 </center>
| width="34%" |
<center> 7mA (1 capteur)</center>
| width="33%" |
<center>4.5µA</center>
| width="33%" |
<center>Disponible</center>
|-
| width="33%" |
<center>STM32L4 Series (STM32L476JE)</center>
| width="34%" |
<center> 100 μA/MHz</center>
| width="33%" |
<center>120 nA</center>
| width="33%" |
<center>$5</center>
|-
| width="33%" |
<center>Raspberry</center>
| width="34%" |
<center> 200mA </center>
| width="33%" |
<center>200mA</center>
| width="33%" |
<center>Disponible</center>
|}

{| class="wikitable centre" width="80%"
|+
|-
! scope=col | '''Module BLE'''
! scope=col | Consommation
! scope=col | Options d'alimentation
! scope=col | Prix
|-
| width="33%" |
<center>BLE Mini</center>
| width="34%" |
<center> 15 mA </center>
| width="33%" |
<center>3.4V à 11V VIN / 5V USB / Coin Cell Battery (2025 or 2032) / 3.7V Li-ion Battery</center>
| width="33%" |
<center>$17</center>
|}

* <s> Le système Mini Arduino/ BLE Mini me semble être un bon compromis entre facilité d’intégration, consommation d'énergie et miniaturisation du système.</s> (Choix à discuter à la réunion du Merdredi 07/10)
* Choix du module RFduino

{| class="wikitable centre" width="80%"
|+
|-
! scope=col | '''Capteurs'''
! scope=col | Modèle
! scope=col | Alimentation min/max
! scope=col | Prix
|-
| width="33%" |
<center>Température</center>
| width="34%" |
<center> TMP36GT9Z </center>
| width="33%" |
<center>2.7V/5.5V</center>
| width="33%" |
<center>1,46 €</center>
|-
| width="33%" |
<center>Accéléromètre</center>
| width="34%" |
<center> ADXL345BCCZ </center>
| width="33%" |
<center>2V/3.6V</center>
| width="33%" |
<center>5,54 €</center>
|-
| width="33%" |
<center>Gyroscope+Accéléromètre</center>
| width="34%" |
<center> MPU-6050</center>
| width="33%" |
<center>2.5V/3.6V</center>
| width="33%" |
<center>15,73 €</center>
|-
| width="33%" |
<center>Pression atmosphérique / Altitude</center>
| width="34%" |
<center> MPL3115A2 </center>
| width="33%" |
<center>1.95V/3.6V</center>
| width="33%" |
<center>2,65 €</center>
|}

* Pour minimiser les pertes on cherche a travailler avec une tension d'alimentation la plus faible possible. Je propose de travailler avec une tension d'alimentation de 3,3V (Validé à discuter à la réunion du Merdredi 07/10)

* Le système de récupération d'énergie fonctionnant sur la base d'un mouvement, j'ai choisi l'ensemble des capteur ci dessus qui me semble être adapté à l'intégration dans un système en mouvement. (Validé à discuter à la réunion du Merdredi 07/10)

* Récupération des modules RFduino, prise en main

===Semaine 3 (12/10/2015)===

* Installation des librairies

* Visualisation d'exemples

* Tests d'implantation du code source du projet P14: Aimant intelligent de la session IMA4: 2014/2015

* Optimisation du code pour la réduction de la consommation d'énergie

* Recherches sur d'autres composants dans l'optique d'une consommation toujours plus faible

{| class="wikitable centre" width="80%"
|+
|-
! scope=col | '''Capteurs'''
! scope=col | Modèle
! scope=col | Alimentation min/max
! scope=col | Prix
! scope=col | Consommation (typ/max)
|-
| width="33%" |
<center>Température</center>
| width="34%" |
<center> STLM20W87F </center>
| width="33%" |
<center>2.4V/5.5V</center>
| width="33%" |
<center> 0,775 € </center>
| width="33%" |
<center> 4.8 μA/8.0 μA </center>
|}

'''Calcul théorique de la consommation énergétique du module BLE + RFD22301'''

Mode "endormi" : ARM CPU Running Current + Output standard drive current = 4 + 0.5 = 4.5mA

Mode "acquisition": ARM CPU Running Current + Output high drive current = 5 + 4 = 9mA

Mode "transmission" : ARM CPU Running Current + Transmit Current + Output standard drive current = 4 + 0.5 + 12 = 16.5mA

http://www.rfduino.com/wp-content/uploads/2014/03/RFD22301.Data_.Sheet_.11.24.13_11.38PM.pdf

'''Code possible du mode "endormi"'''

pinMode(5, INPUT);
RFduino_pinWake(5, HIGH);

RFduino_ULPDelay(INFINITE);
if (RFduino_pinWoke(5))
{
state = ! state;
RFduinoGZLL.sendToHost(state);
}

http://forum.rfduino.com/index.php?topic=385.0

===Semaine 4 (19/10/2015)===

* Réunion du 21/10

* Réalisation de tests

* Ajustement du nombre de capteurs : dans un premier temps on utilisera le capteur de température puis l'accéléromètre

* Discussion sur le bac de test et méthodes de test : résistance de visualisation, chronométrage du temps de transmission, vitesse du processeur

* Réalisation des premiers relevés

===Semaine 5 (26/10/2015)===

* Recherche bibliographique sur les modes d'endormissement du module RFduino

* Essais de codes utilisant un mode d'endormissement plus profond

* Réalisation de graphique de l'énergie utilisée par le module lors de la transmission d'un message par le module BLE.

* Recherches sur des méthodes de programmation pour la diminution de la vitesse processeur

[[Fichier:P32Montage.jpg|250px|thumb|left|'''Montage de test''']]
[[Fichier:P32resultats.jpg|250px|thumb|center|'''Visualisation du courant consommé lors d'envoi toutes les 10ms''']]

* On visualise à l'oscilloscope des pic d'envoi et des pic d'avertissement de la balise BLE, on peut ainsi déduire la puissance nécessaire de chaque action

===Semaine 6 (02/11/2015)===

* Test de diminution de la vitesse processeur

* Réalisation de graphique démontrant l'impact de la réduction de la vitesse processeur sur l'énergie consommée et déduction d'une vitesse optimale pour notre application

* Réunion du 4/11

Définition d'objectifs : Création d'un fichier excel permettant de caractériser les coûts en énergies de chaque étapes de fonctionnement du système.

* Création d'un environnement de test "normé" ( Pour éviter les variations de mesures on réalise un banc et on applique les mêmes conditions de test pour chaque essai)

* Recherche bibliographique sur la norme BLE : recherche du temps maximum entre deux "avertissements" de la balise BLE

===Semaine 7 (09/11/2015)===
* Explication du principe de communication BLE pour l'exploitation des résultats

[[Fichier:Freq.PNG]]

Nous nous intéressons dans notre projet à "l'observateur". Cet objet peut avoir trois états : stand-by, advertising et en communication.

[[Fichier:Brod2.png]]

Dans le mode "Advertising" le système peut :

- Avertir le système récepteur de la proximité d'un capteur

- Avertir de la présence à un appareil souhaitant ce connecter

- Ce reconnecter de façon asynchrone

===Semaine 8 (16/11/2015)===

Analyse en détail d'une trame BLE

[[Fichier:Com.PNG]]

On constate que pendant la durée de la trame il y a un échange entre les deux objets appairé. On s’intéresse ici uniquement aux actions "Slave Tx". Le but étant d'identifier la durée et le courant consommé par ces actions pour obtenir des valeurs en joules.

[[Fichier:SchemaCom.PNG]]

On constate donc deux phases :

- Advertising event

- Connexion event

Nous allons essayer de retrouver et quantifié l'énergie consommé dans ces deux phases.

===Semaine 9 (23/11/2015)===

Lors de cette semaine nous avons effectué des tests en respectant une procédure de test précise. En effet les valeurs des courants que nous relevons sont très petites aussi chaque variation du montage est susceptible de perturber les valeurs.

[[Fichier:P32Conne.jpg|250px|thumb|left|'''Phase connexion''']]

[[Fichier:Avertissement.jpg|250px|thumb|center|'''Phase Advertising''']]

===Semaine 10 (30/11/2015)===

- On cherche a diminuer légèrement la consommation par des modifications logiciel :

Réduction de la puissance de la radio BLE : Diminution de la portée

Augmentation de la fréquence d'advertising : tant que la fréquence d'advetising est inférieure a cette de relevé des capteurs on s'assure que la donnée envoyée est toujours mise à jour.

[[Fichier:Pwl20-envoi.jpg|250px|thumb|left|'''Avec modification logiciel''']]

[[Fichier:Sans-pwlvl.jpg|250px|thumb|center|'''Sans modification logiciel''']]

- On concentre nos résultats dans un tableau récapitulatif en vue du dimensionnement de la batterie du système

[[Fichier:P32tbresul.PNG]]

===Semaine 11 (07/12/2015)===

Tests d'intégration de plusieurs capteur et observations des modification de la consommation des ADC et de la durée/consommation de la transmission.

Réunion de vérification des tests.

Mise en évidence de la dualité consommation d'énergie - Temps de réponse du système

En effet chaque "Advertisement" consomme une quantité d'énergie nous pouvons gérer l'espacement entre ceux-ci mais plus ce temps serra élevé plus il faudra de temps pour ce connecter à ce périphérique.

* Rédaction d'un rapport de test

* Rédaction du rapport de pré soutenance

===Semaine 12 (14/12/2015)===
===Semaine 13 (04/01/2016)===
===Semaine 14 (11/01/2016)===
===Semaine 15 (18/01/2016)===
===Semaine 16 (25/01/2016)===
===Semaine 17 (01/02/2016)===
===Semaine 18 (08/02/2016)===
===Semaine 19 (15/02/2016)===
===Semaine 20 (22/02/2016)===

== Annexes ==

Consommation du STM32L4 Series : http://www.st.com/web/en/catalog/mmc/FM141/SC1169/SS1580?sc=stm32l4

Réduction de la consommation de l'Arduino : http://www.home-automation-community.com/arduino-low-power-how-to-run-atmega328p-for-a-year-on-coin-cell-battery/

Consommation Raspberry : https://www.raspberrypi.org/help/faqs/

Module BLE : http://redbearlab.com/blemini/

Accéléromètre : http://fr.farnell.com/analog-devices/adxl345bccz/accelerometre-3-axes-14lga/dp/1853935

Capteur température : http://fr.farnell.com/analog-devices/tmp36gt9z/capteur-temp-to-92-3/dp/1438760?ost=TMP36GT9Z
ou http://fr.farnell.com/stmicroelectronics/stlm20w87f/capteur-de-temperature-analog/dp/1391131

Accéléromètre + Gyroscope : http://fr.farnell.com/invensense/mpu-6050/gyroscope-accelero-6-axes-i2c/dp/1864742

Altimètre : http://fr.farnell.com/freescale-semiconductor/mpl3115a2/pressure-sensor-20-110kpa-8lga/dp/2009084?ost=MPL3115A2&categoryId=700000004367

Explications norme BLE : chapters.comsoc.org/vancouver/BTLER3.pdf

http://www.argenox.com/bluetooth-low-energy-ble-v4-0-development/library/a-ble-advertising-primer/

== Rapport de Mi-projet ==

[[Fichier:CR_Miprojet_Sultana.pdf‎ ]]