P26 Réseau de capteurs de pollution : Différence entre versions

De Wiki de Projets IMA
(→‎Planning)
(→‎Tâches à réaliser)
Ligne 16 : Ligne 16 :
 
* Réalisation de la carte électronique
 
* Réalisation de la carte électronique
 
** Programmation
 
** Programmation
−
** Réalisation du montage & tests
 
 
** Design sur ordinateur
 
** Design sur ordinateur
 
** Gravure & soudage
 
** Gravure & soudage
 +
** Tests
 
* Application Android
 
* Application Android
−
* Base de données
+
* API REST et base de données
  
 
===Matériel fourni===
 
===Matériel fourni===

Version du 9 février 2018 à 13:53

Etudiante : Marianne Butaye
 Encadrants : Alexandre Boé, Xavier Redon & Thomas Vantroys

Présentation générale du projet

Actuellement, seuls deux capteurs de pollution sont présents sur la métropole, un à Lille et l'autre à Fives. Une carte de pollution de la zone est générée à partir de ces deux capteurs et d'un algorithme tenant en compte les déplacements des nuages. L'objectif serait de pouvoir avoir une carte de la pollution en temps réel dont les données seraient obtenues à partir d'objets connectés. Chaque personne se déplaçant avec un de ces objets contribuerait à fournir des informations pour compléter la carte de pollution.

L'objet connecté prendrait la forme d'une carte portative, qui pourrait être attachée sur un brassard ou un vélo. La carte portative enverrait des relevés par bluetooth à un téléphone Android, qui lui-même les enverrait ensuite par la 3G à une base de données. Il sera également possible d'effectuer ces transmissions par une puce LORA, au choix de l'utilisateur.

La carte électronique sera composée au minimum d'un capteur de particules, d'un micro-contrôleur, d'une puce bluetooth et d'une puce LORA. On pourrait éventuellement rajouter d'autres capteurs comme un capteur de pression atmosphérique, un accéléromètre etc.

Cahier des charges

Tâches à réaliser

Ce projet se découpe en différentes parties :

  • Mini état de l'art
  • Réalisation de la carte électronique
    • Programmation
    • Design sur ordinateur
    • Gravure & soudage
    • Tests
  • Application Android
  • API REST et base de données

Matériel fourni

  • 1 boîte en plastique pour stocker le matériel
  • 1 câble USB/mini USB
  • 1 carte STM32F401RE nucleo
  • 1 shield Bluetooth nucleo (BLE IDB04A1)
  • 1 kit d'évaluation ST microelectronics. La carte possède une puce Bluetooth et un STM32 ainsi que des capteurs divers. Une application Android est disponible sur le site de ST microelectronics.
  • 1 téléphone Android LG G4C
  • 2 capteurs de particules
  • 1 board pour passer du câble à des PINs
  • Des convertisseurs 3.3V -> 5V
  • 1 SensorTile Module (STM32 + bluetooth + capteurs + antenne)
  • 1 module GPS programmable DS-GPM
  • des câbles MM et FF

Planning

Répartition du travail effectué
Tâche Sous-tâche Semaine 1 Semaine 2 Semaine 3 Semaine 4 Semaine 5 Semaine 6 Semaine 7
Réunion avec les encadrants x x
État de l'art x
Carte électronique Programmation du micro-contrôleur x x x x
Design sur ordinateur x x x
Gravure & soudage x
Tests
Application Android x x x x
API REST et base de données x

Avancement du projet

Semaine 1 (du 08/01/2018 au 14/01/2018)

Je commence par rencontrer mes encadrants de projet afin d'établir le contexte et les objectifs de celui-ci, de récupérer le matériel et le travail déjà commencé auparavant.

La première chose à faire est de réaliser un mini état de l'art, pour mieux s'approprier le sujet.

État de l'art

Les équipements pour mesurer la pollution étant trop chers et donc réservés aux experts, les micro-capteurs de pollution ont fait leur apparition. Ceux-ci sont plus légers, portables, peu chers, faciles à utiliser et connectés. Les capteurs de particules fonctionnent par détection optique par diode laser. On aspire d'abord l'air par un ventilateur, qui circule ensuite dans une chambre de détection. La chambre permet de séparer les particules pour ne garder que les plus fines (les plus dangereuses). Le flux d'air chargé de particules traverse ensuite le signal optique émis par une diode laser dont le faisceau est diffracté par une lentille. Un photodétecteur placé face au faisceau émis recueille les baisses de luminosité liées au passage des particules. Il compte leur nombre par plages de tailles. À partir du débit de l'air, on peut remonter à une concentration en nombre puis en masse.

On repère plusieurs types de capteurs de pollution : les stations connectées et les capteurs nomades.

Dans les stations connectées, on retrouve les produits Footbot et Koto Air. La première mesure tous les niveaux de pollution, tandis que la seconde n'en mesure pas autant mais relève aussi l'humidité, la température, la luminosité et le niveau de bruit.

Ce projet est de la catégorie des capteurs nomades. On trouve dans cette catégorie le capteur français Flow de la société PlumeLabs, l'Atmo tube, Clarity, un capteur chinois et le Tzoa. Ces capteurs relèvent la plupart différentes pollutions, telles que les particules fines, le monoxyde d'azote, le monoxyde de carbone, l'ozone et les composés organiques volatiles (provenant de la pollution intérieure : moquettes, peintures, colles, plantes etc.). Certains embarquent aussi d'autres capteurs pour par exemple mesurer la température, l'humidité etc. Ces capteurs nomades ont pour principe de relever et traiter les données par le capteur, puis ensuite de les transmettre à une application mobile. Certains ont même vocation à les transmettre à une base de données selon le principe du "crowdsourcing", où les données récoltées sont partagées entre tous les utilisateurs; c'est le cas des capteurs Flow et Clarity.

Enfin, on trouve des capteurs nomades avec une forme un peu plus originale, comme c'est le cas des pulls réalisés par Nikolas Beltel, designer du groupe Aerochromics; ces pulls changent de couleur en fonction du taux de pollution pour des pollutions telles que les particules fines, le monoxyde de carbone ou encore la radioactivité.

Connexion bluetooth entre la carte STM32 et le téléphone

J'ai ensuite abordé en premier la connexion entre la carte STM32 et le téléphone, n'ayant pas encore eu une partie du matériel (le capteur de particules entre autres).

La carte STM32 est programmable grâce à un IDE disponible sur le site de MBed. Cet IDE est disponible en deux versions : en ligne ou à télécharger. J'ai décidé d'utiliser la version en ligne, celle-ci étant facile d'accès. Il suffit de créer un programme en ligne et de le compiler. Le fichier binaire ainsi créé est ensuite automatiquement téléchargé par le navigateur, et un drag&drop sur la carte STM32 (branchée par USB à l'ordinateur) permet de la reprogrammer.

La carte nécessite l'ajout d'un shield bluetooth pour la communication. On utilise ici le modèle BLE IDB04A1, un modèle aujourd'hui obsolète, ce qui a posé quelques problèmes pour la connexion à la carte. Le site de MBed a en effet beaucoup d'exemples et librairies disponibles en ligne, mais les projets BLE_HeartRate_IDB0XA1 et BLE_HeartRate_IDB04A1 ne fonctionnent pas avec ce modèle. Cette version-ci par contre fonctionne en partie. J'ai ainsi pu établir une connexion partielle, en suivant ces instructions puis celles-ci pour la partie Android.

Il s'est avéré que même l'exemple fonctionnant partiellement posait problème lors de l'initialisation du module Bluetooth. Un déboggage manuel a permis de déterminer exactement d'où venait l'erreur : le problème se produit lors de l'initialisation de la communication SPI entre les deux objets. Le problème vient en fait de l'utilisation de la LED : il n'est pas possible de l'utiliser en même temps que le shield Bluetooth. Il faut, pour résoudre ce problème, connecter deux PINs ensemble (le 11 et le 31 du côté CN10 de la carte) par un jumper.

STM32 et shield bluetooth après connexion des PINS 11 et 31

Une fois le problème résolu, on peut voir s'afficher la configuration du module au démarrage de celui-ci sur un terminal connecté en série à la carte.

Une application Android est disponible pour tester les exemples. J'ai ainsi téléchargé l'application STM BLE Profiles sur le Play store. Le dispositif est reconnu et je peux accéder aux informations programmées dans la carte et transmises par Bluetooth.

Un service de l'application Android STM BLE Profiles transmis par la carte

L'intallation d'Android Studio étant particulièrement longue, je n'ai pas encore pu tester la connexion par Bluetooth avec une application Android se connectant aux services que j'ai créé dans le programme de la carte.

Semaine 2 (du 15/01/2018 au 21/01/2018)

Programmation du capteur de particules

Le capteur de particules est le SEN0177. On peut le connecter à un micro-contrôleur par 4 fils : VCC (5V), GND, TX et RX. Ce capteur est livré avec une carte adaptateur pour passer du connecteur à des PINs traditionnels. Il fonctionne selon une trame préétablie que l'on peut récupérer sur le site du constructeur (voir la bibliographie). On y trouve également un programme d'exemple pour Arduino que je me suis chargée de transcrire pour le faire fonctionner sur l'environnement de développement MBed.

Connexion du capteur de particules SEN0177 à la carte STM32

Une chose importante est de ne pas se tromper sur le branchement des fils : le RX de l'adaptateur doit être connecté au TX de la STM32 et son TX au RX de la STM32. Il a aussi fallu faire attention à ne pas mettre trop de printf dans le code du programme : en effet, ceux-ci ralentissent le programme et on peut ainsi ne récupérer aucune donnée par la connexion série même si le programme est correct. Enfin, une dernière difficulté a été de trouver les bons noms des PINs à utiliser dans le programme; il est ainsi nécessaire de n'utiliser que les noms des PINs en vert ou en bleu du Pinout.

Pour récupérer les valeurs des particules fines de type 1.0, 2.5 et 10, il faut commencer par détecter si on a bien le début de la trame en liaison série, c'est-à-dire 0x42 suivi de 0x4D. On pourra ensuite trouver les valeurs dans les données reçues.

Dans les bâtiments de l'école, j'obtiens les valeurs de pollution suivantes, qui sont assez faibles. 

PM1.0: 2 ug/m3
PM2.5: 5 ug/m3
PM10: 6 ug/m3

PM1.0: 3 ug/m3
PM2.5: 5 ug/m3
PM10: 5 ug/m3

PM1.0: 3 ug/m3
PM2.5: 5 ug/m3
PM10: 5 ug/m3

PM1.0: 3 ug/m3
PM2.5: 5 ug/m3
PM10: 5 ug/m3

PM1.0: 4 ug/m3
PM2.5: 6 ug/m3
PM10: 6 ug/m3

Le capteur contient un ventilateur qui aspire les particules et une sortie d'air, il ne faut donc pas les obstruer pour obtenir de bonnes valeurs.

Programmation du module GPS

Je ne peux pas programmer le véritable module GPS pour le moment car celui-ci est trop petit. C'est pour cela que j'ai effectué la programmation du module en utilisant un autre module à taille plus grande en attendant de pouvoir réaliser la carte. Le module obtenu est un DS-GPM. Celui-ci fonctionne sous une tension allant de 7 à 16V, je vais donc le connecter à une pile 9V.

Les GPS sont en général connectés par des liaisons classiques : séries avec RX et TX, SPI ou I2C. Ce module fonctionne en I2C, on va donc brancher 4 PINs : VCC(7->16V), GND, SDA et SDL.

Connexion du module GPS DS-GPM à la carte STM32

De même, le site du constructeur permet le téléchargement d'un programme d'exemple Arduino et de la Datasheet. Les valeurs du GPS sont facilement récupérables : les données sont contenues dans 112 registres. Il suffit de récupérer ceux souhaités. L'interface I2C sur MBed permet également de récupérer d'un seul coup la totalité des registres.

Ce capteur ne fonctionne pas en intérieur. J'ai réussi à lire les registres mais étant en intérieur, je n'ai pas pu obtenir de valeurs exploitables.

Création du schematic de la carte sous Altium Designer

J'ai reçu la liste du matériel disponible entre temps, ainsi qu'une librairie pour Altium contenant certains composants déjà réalisés. J'ai ainsi commencé par faire ceux qui manquaient puis par réaliser un début de schéma.

Pour le composant Sensor Tile (ou ultra low power DSP STM32L476JGY6), qui contient à la fois un micro-contrôleur STM32, un module bluetooth et des capteurs divers, j'ai dû consulter le peu de datasheet existant puis me référer à la datasheet du composant STM32L476.

Liste des composants :

  • HDC1080DMBR (capteur d'humidité et de température)
  • TMP302DDRLR (switch de température)
  • DPS310XTSA1 (baromètre et capteur de température)
  • PCF8563T (horloge et calendrier temps réel)
  • 538-47346-1001 (connecteur micro-USB)
  • AMCA31-2R450G-S1F-T (antenne Bluetooth/WiFi)
  • 146235-0001 (antenne GPS)
  • AP3417CKTR-G1 (régulateur de tension)
  • SN74LV1T34DCKR (buffer et modificateur de tension)
  • BSS84-7-F (switch MOSFET)
  • MAX4378TAUD+ (mesure de consommation)
  • STLCS02V1 - SensorTile (microcontrôleur STM32 + module Bluetooth + micro + baromètre + capteur de température + accéléromètre + magnétomètre + gyroscope)
Pins et fonctions du composant Sensor Tile
Connexion par Bluetooth entre STM32 + module bluetooth et téléphone Android

J'ai également poursuivi le travail sur la connexion par Bluetooth. Maintenant que la carte est capable de transmettre des données, j'ai créé une application Android capable de communiquer en BLE (Bluetooth Low Energy). J'ai d'abord commencé par télécharger des applications existantes sur le Play Store pour essayer de détecter la combinaison carte + module bluetooth.

J'ai notamment découvert par expérimentations que le nom de l'application ne doit pas dépasser 14 caractères ni ne contenir d'espaces, ou que les dernières versions de librairies mbed ne permettaient pas au module BLE de fonctionner correctement. Il est donc important de ne pas mettre à jour les librairies lors de l'importation du projet, et de ne pas oublier de connecter le jumper (voir semaine 1).

Une fois l'appareil Pollution détecté dans la liste des appareils connectés en Bluetooth, il est possible de le sélectionner et d'afficher la liste des services qu'il publie. En effet, chaque appareil bluetooth publie des services. Un service regroupe des caractéristiques qui vont bien ensemble. Ces caractéristiques peuvent ensuite être de type lecture, écriture ou les deux. Pour les caractéristiques que l'on peut lire, on peut ainsi obtenir la ou les valeurs associées. Par exemple, pour un service Service Pollution, on pourrait avoir une caractéristique Niveau de pollution ainsi qu'une autre Niveau d'humidité.

Après de nombreux essais, j'ai enfin réussi à détecter le service de pollution envoyé par la carte. C'est grâce à l'ajout de l'adresse 0xFFFF dans la liste de diffusion des services, ce qui semble avoir mis à jour le cache. La carte peut en effet annoncer les services qu'elle contient. Cela n'est pas obligatoire pour que le bluetooth fonctionne mais permet de donner une bonne indication du fonctionnement de l'application. L'adresse 0xFFFF est réservée au développement.

J'ai enfin créé ma propre application Android par la suite pour récupérer correctement la valeur de la pollution. Celle-ci est par défaut considérée comme de l'hexadécimal, or nous souhaitons obtenir un entier. J'ai aussi ajouté le service de niveau de batterie (utile pour un objet connecté qui fonctionnera possiblement sur piles ou autres et dont on voudra vérifier la durée de vie) et le service d'information sur l'appareil (ici, la carte électronique).

  • Scan sur Android et liste des appareils détectés

  • Liste des services de l'application Pollution sur Android

  • Application personnalisée pour le capteur de pollution

Semaine 3 (du 22/01/2018 au 28/01/2018)

Suite du travail sur le schematic de la carte

Cette semaine, j'ai commencé par poursuivre le schematic de la carte électronique sous Altium. J'ai pour cela téléchargé et consulté les différentes datasheets des composants. Cela m'a permis d'établir une liste de points/questions à aborder avec mes tuteurs, parmi lesquels l'obtention de références manquantes de composants, comment effectuer la connexion/déconnexions entre les différents éléments du schéma etc. J'ai aussi créé la partie PCB de la carte sous Altium pour commencer à entrer la configuration des règles à respecter et d'ores et déjà créer des plans de masse.

Suite du travail sur l'application Android

J'ai également poursuivi le travail sur l'application Android pour la communication en Bluetooth. En effet, l'application a été créée à partir d'un projet d'exemple généré automatiquement, j'ai donc d'abord nettoyé un peu le code qui ne servirait pas ou plus.

La carte comportera plusieurs capteurs, il est donc important de pouvoir afficher et récupérer plusieurs caractéristiques du service de pollution. J'ai donc dans ce but ajouté une liste des éléments sur la page d'accueil et affiché les deux caractéristiques principales pour le moment, le niveau de particules et la batterie restante. Le bluetooth Low-Energy sous Android est fait de telle manière que seule une action de lecture ou d'écriture est possible à la fois. Cela signifie surtout que pour pouvoir obtenir les valeurs des deux caractéristiques citées précédemment, il faut mettre en place une file d'attente (ou queue en anglais) pour que les actions soient effectuées les unes à la suite des autres. Il existe différents types de files d'attentes sous Java ou Android, j'ai pour ma part employé une liste de type FIFO (First In First Out). La LinkedList de Java convient parfaitement dans ce cas-ci.

Un autre point important concerne l'affichage de la liste. En effet, une fois les bonnes valeurs des capteurs récupérées par Bluetooth, on souhaite pouvoir les mettre à jour dans la liste. Il a donc été nécessaire de rafraîchir l'affichage de la liste pour obtenir ces changements.

Services de pollution et de batterie sur l'application Android

J'ai aussi travaillé sur les notifications. J'ai d'abord commencé par modifier le programme du module bluetooth, pour lui faire envoyer des mises à jour des valeurs des capteurs. La LED clignotante permet de vérifier que les mises à jours sont bien envoyées. Il est possible, sous Android, de souscrire à des notifications pour être tenu au courant des changements de valeurs des capteurs. Il est pour cela nécessaire d'indiquer que l'on souhaite recevoir les notifications et il faut donner une valeur à un descripteur particulier (les descripteurs permettent d'ajouter des configurations sur les caractéristiques). Je n'ai malheureusement pas encore réussi à observer de réception des notifications.

Semaine 4 (du 29/01/2018 au 04/02/2018)

Réunion avec mes tuteurs

La semaine a commencé avec une réunion avec M. Boé, sur le sujet de la carte électronique. J'ai ainsi pu obtenir les références manquantes des modules GPS et LORA.

J'avais également quelques questions à lui poser et cette réunion m'a permis d'obtenir les informations suivantes :

  • Les différents éléments doivent pouvoir être connectés ou déconnectés facilement. Pour ceci, on utilisera des jumpers et des headers. Les headers seront mis sur la carte pour simuler une ligne coupée et les jumpers permettront de connecter/déconnecter cette ligne.
  • Le switch de température donné dans la liste de composants ne sera pas utilisé.
  • On pourra accéder aux sorties de mesures de courant grâce à des headers.
  • Le module SensorTile sera alimenté en 3.3V. Il est normalement alimenté en 1.8V, mais il (et tous ses capteurs) est capable de supporter du 3.3V, alors qu'au contraire certains capteurs ne fonctionneront pas avec une tension inférieure à 3V. L'alimentation se fera sur la broche VDD sur SensorTile.
  • La carte pourra soit être alimentée en 5V, tension qui grâce au régulateur de tension sera transformée en 3.3V, soit directement en 3.3V. Les tensions 5V et 3.3V peuvent être obtenues par des headers ou pour le 5V par le port micro-USB.
  • Le module SensorTile dispose d'un pin pour la fonctionnalité USB On-The-Go, qui ne sera pas utilisée pour le moment. Un header permettra quand même une possible future utilisation de celui-ci. Ce port doit être alimenté en 3.3V.
  • On n'utilisera pas le baromètre de la liste de matériel, car le SensorTile dispose déjà d'un capteur similaire.

Liste des composants supplémentaires :

  • M10578-A2 (module GPS)
  • RN2483A-I/RM103 (module LORA)
Réalisation du schematic et du PCB

J'ai ensuite continué et terminé la réalisation du schematic et du PCB associé, et ai envoyé ceux-ci pour validation auprès de M. Boé. Ce fut la première version de la carte (visible ci-dessous).

  • Schematic complet, première version

  • Couche Top du PCB, première version

  • Couche Bottom du PCB, première version

La révision de M.Boé m'a permis de remarquer quelques problèmes et changements a effectuer (notamment la taille des composants SMD comme les résistances et les capacités, ou le fait que le capteur de particules fonctionne sur du 5V). C'est la troisième version qui sera la finale, après quelques modifications supplémentaires au niveau des vias de masse et des antennes.

L'étape suivante consiste à imprimer la carte sur papier en taille réelle et poser les composants dessus pour vérifier les tailles des empreintes. Je n'ai malheureusement pas les composants, cette vérification devra donc attendre la semaine suivante.

  • Schematic complet, version finale

  • Couche Top du PCB, version finale

  • Couche Bottom du PCB, version finale

Suite de la programmation de la carte STM32

La carte embarque de nombreux capteurs, il faudra donc pouvoir relever et transmettre ces valeurs au téléphone Android. J'ai donc commencé par créer de nombreux programmes, un pour chaque capteur, dans le but de relever leurs valeurs. Ainsi, certains d'entre eux communiquent avec le protocole I2C, comme c'est le cas du capteur d'humidité, de pression barométrique ou du RTC. Pour lire ces valeurs, il faut connaître l'adresse du capteur et faire une écriture sur le registre que l'on souhaite lire. On peut ensuite y faire une lecture et récupérer son contenu. Certains capteurs nécessitaient aussi une configuration préalable qui consistait à écrire certaines valeurs dans les registres de configuration.

D'autres capteurs (notamment le GPS, le module LORA et le capteur de particules) fonctionnent en écriture/lecture sur le port série. Ceux-ci se lisent plutôt facilement et on peut distinguer à qui appartiennent les valeurs en lecture par le début de chaque trame. Le capteur de particules par exemple écrira d'abord 0x42, alors que le GPS écrira '$'.

Le GPS, d'ailleurs, suit un protocole spécifique pour la forme de ses données; c'est le protocole NMEA 0183. Ce protocole permet de recevoir des trames de différents formes, une des plus connues étant la forme GGA. Je ne sais pas encore quels types de trames envoie ce module GPS car je ne peux pas tester mes programmes, n'ayant pas encore gravé la carte; mais je suis partie du principe pour réaliser le code que la trame était de forme GGA. Un exemple de trame se trouve ci-dessous : 

$GPGGA,064036.289,4836.5375,N,00740.9373,E,1,04,3.2,200.2,M,,,,0000*0E

On y retrouve ainsi le type de la trame, l'heure d'envoi de celle-ci, la latitude, la longitude, l'altitude, le nombre de satellites utilisés pour calculer les coordonnées et d'autres informations diverses et variées.


Il est ensuite important de pouvoir transmettre ces données. J'ai donc créé de nouveaux services et caractéristiques pour l'envoi via le Bluetooth. J'ai essayé au maximum de reprendre les services qui existaient déjà pour cela.

Il existe ainsi un service Environmental Sensing Service qui peut embarquer de nombreuses caractéristiques, notamment la température, l'humidité ou a pression atmosphérique. J'ai malheureusement découvert au cours de mes expérimentations que je n'arrivais pas à transmettre plus de deux caractéristiques par services. La troisième se transformait automatiquement en valeur supplémentaire de la seconde caractéristique déclarée. Je me suis donc arrangée en laissant l'humidité et la pression au service ci-dessus et j'ai transféré la température dans le Pollution Service créé précédemment.

Un autre service est le Location and Navigation Service qui lui contient les données relatives à la positions telles que celles transmises par le GPS. Pour cette caractéristique, et afin de respecter la limite de deux caractéristiques par service, j'ai dû créer et envoyer des données sous forme de structure de données. En effet, cette structure (qui correspond au contenu de la caractéristique déclarée dans la documentation officielle) commence par des bits indiquant les valeurs à suivre, puis on y retrouvera à la suite la latitude, la longitude et l'altitude. La documentation indiquait cependant qu'une transformation devait être appliquée aux données issues des capteurs, afin de les transmettre sous forme d'entiers alors qu'elles étaient sous forme décimale. Dans ce cas-là, il fallait faire valeur x 10^7 pour le GPS d'après la documentation, mais j'ai été obligée de me limiter à 10^5, les valeurs n'ayant plus de sens au delà.

Enfin, le dernier service utilisé est le Current Time Service qui permet de stocker la date et l'heure obtenus à partir du RTC. J'ai pu débugger ces services et caractéristiques en utilisant des applications Android de base pour le Bluetooth Low Energy qui connaissent tous ces services standards (ici, j'ai utilisé l'application nRF Connect).

Débuggage des services et caractéristiques par une application Android
Suite de la programmation sur Android

Suite à l'ajout de services sur la carte STM32, j'ai également dû modifier le code Java pour Android afin de recevoir et d'afficher ces valeurs. J'ai ainsi ajouté de quoi recevoir ces données en déclarant les nouveaux services mais j'ai aussi dû appliquer les mêmes transformations que sur la STM32 mais à l'inverse. Ainsi, si avant j'appliquais valeur x 10^5, j'applique maintenant valeur reçue / 10^5.

L'envoi pas Bluetooth transforme également les trames des structures de données en inversant les bytes. Ainsi, par exemple si on décide d'envoyer la trame 200 3000 par la STM32, les bytes transmis seront 00 C8 0B B8. Or ceux-ci seront reçus dans l'ordre suivant sur Android : C8 00 B8 0B. Il faut donc commencer par découper la trame en les différentes valeurs qui nous intéressent puis inverser le tableau obtenu pour chaque valeur.

J'ai eu du mal lors de l'ajout de services supplémentaires lorsqu'ils étaient composés d'une trame de données. La réception n'est pas plus dure, mais la trame contient plusieurs valeurs, il faut donc en général mettre plusieurs affichages à jour. J'avais tout d'abord essayer de publier (par la méthode sendBroadcast) plusieurs fois dans la même fonction broadcastUpdate. Il s'est cependant vite avéré que c'était une mauvaise idée : si on a par exemple deux ordres de lecture dans la file d'attente A puis B; et que A effectue deux sendBroadcast, alors on aura : 

A et B sont dans la file d'attente
On lit la 1ère valeur, A.
A effectue deux sendBroadcast, A1 et A2 et est supprimé de la file d'attente.
A1 indique que des données sont disponibles et qu'il faut les afficher. La file d'attente n'est pas vide, on lit B, qui effectue un sendBroadcast B1 et est supprimé de la file d'attente.
en parallèle || Pendant ce temps-là, A2 indique que des données sont disponibles et qu'il faut les afficher. La file d'attente est vide.
             || B1 n'est pas lisible car A2 est en train d'être lu

J'ai réussi à résoudre le problème en créant un nouveau type, BLENumberedCharacteristic qui est une simple combinaison d'une BluetoothGattCharacteristic et d'un entier représentant le numéro de la valeur de la caractéristique à lire/afficher. Cette classe remplace la précédente dans la file d'attente et on met l'entier de la valeur de caractéristiques dans une variable à chaque utilisation de la fonction updateNextCharacteristic. J'ai été obligé de programmer cela de cette manière car je ne pouvais pas ajouter ce numéro en paramètre à la fonction onCharacteristicRead, qui est une fonction de Callback overridée et donc prédéfinie. Ainsi, pour une position reçue par le GPS, lors de la mise en file d'attente, on mettra en fait trois instances de la même caractéristique en file d'attente, chacune avec un numéro différent; 1 pour la latitude, 2 pour la longitude et 3 pour l'altitude.

Les différentes valeurs reçues sur l'application Android

Semaine 5 (du 05/02/2018 au 11/02/2018)

Semaine 6 (du 12/02/2018 au 18/02/2018)

Semaine 7 (du 19/02/2018 au 25/02/2018)

Bibliographie

Annexes

Récupérée de « https://projets-ima.plil.fr/mediawiki/index.php?title=P26_Réseau_de_capteurs_de_pollution&oldid=50443 »